New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can.view.preload breaks can.view.attr #1032

Closed
Bajix opened this Issue May 30, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@Bajix

Bajix commented May 30, 2014

Any handlers registered via can.view.attr after can.view.preload don't run.

http://jsfiddle.net/ukq7s/

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 2, 2014

Contributor

@moschel emailed me:

Looked into this a little tonight and it happens because the can.stache method is when all the can.view.attr callbacks are set up, so if a can.view.attr is registered after the template is parsed and preloaded, it won't run, even if the renderer function is run later.

I think this would cause can.view.attr callbacks to not work in steal production mode, right? If so this would be a bigger bug.

Contributor

justinbmeyer commented Jun 2, 2014

@moschel emailed me:

Looked into this a little tonight and it happens because the can.stache method is when all the can.view.attr callbacks are set up, so if a can.view.attr is registered after the template is parsed and preloaded, it won't run, even if the renderer function is run later.

I think this would cause can.view.attr callbacks to not work in steal production mode, right? If so this would be a bigger bug.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 2, 2014

Contributor

Yes, this is a "wont-fix". The only alternative would be to re-process each template anytime anyone calls can.view.attr. Instead just make sure can.view.attr is called first.

@moschel this will work fine in production if you make sure the templates depend on the module that calls can.view.attr (which will have to be done with deps.

Contributor

justinbmeyer commented Jun 2, 2014

Yes, this is a "wont-fix". The only alternative would be to re-process each template anytime anyone calls can.view.attr. Instead just make sure can.view.attr is called first.

@moschel this will work fine in production if you make sure the templates depend on the module that calls can.view.attr (which will have to be done with deps.

@Bajix

This comment has been minimized.

Show comment
Hide comment
@Bajix

Bajix Jun 2, 2014

Makes sense. This should be explicitly documented at the very least.

Bajix commented Jun 2, 2014

Makes sense. This should be explicitly documented at the very least.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 2, 2014

Contributor

Sure, can you add it and submit a pull request?

Contributor

justinbmeyer commented Jun 2, 2014

Sure, can you add it and submit a pull request?

@justinbmeyer justinbmeyer reopened this Jun 2, 2014

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 2, 2014

Contributor

This might be worth figuring out if we want to support dynamically importing components.

Contributor

justinbmeyer commented Jun 2, 2014

This might be worth figuring out if we want to support dynamically importing components.

@Bajix

This comment has been minimized.

Show comment
Hide comment
@Bajix

Bajix Jun 2, 2014

I'm not sure what you mean here; Components defined after can.view already work.

Bajix commented Jun 2, 2014

I'm not sure what you mean here; Components defined after can.view already work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment