-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
UI: Adds controller lifecycle reset
hook
#5056
Conversation
98a209f
to
0788ea6
Compare
Code LGTM but why not create a separate mixin for |
Also: tests? |
Hey Greg! 👋 Thanks for taking a look at this much appreciated! Hopefully I can allay your worries! 😄 Do you mean have a If so, potentially I could do that, but as they are doing the exact same thing (performing cleanup/teardown when something is no longer on the page) I feel its best to keep that in the one place. The only reason there is some logic here is that Ember doesn't seem to have a generic name/hook for performing an action when an object is no longer on the page. Options:
What would your preference be there ^ ? Or can you think of any other options I could use?
Could you explain in more detail what these issues or side-effects might be? If there is something that might affect us I'd rethink this.
This is generally plumbing, not logic/functionality.
Thanks John |
Hey @gregone ! Not sure if you meant to hit the approve button here or not (maybe you did? with the LGTM?), but I'll probably merge this tomorrow unless you have any major issues with me doing that. Shout me if you want to discuss anything, I'll probably wait until past midday before I merge. Thanks! John |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have still have thoughts on the mixin location, but that can be refactored later if needed.
This adds a
Controller.reset
hook through my app, right now it's mainly used if you use theWithListeners
mixin in aController
Also see #4789 (comment) which is partly related to this and the discussion above that comment gives some background on the inclusion/omission of a setup-like hook. The likelihood is we will add one 🔜 , just we don't think it should be called
setup
as it could potentially be called when you aren't 'setting up'.This also adds an improvement to the dynamic 'psuedo-super' call, just to bind the method correctly so
this
remains what it should be if there is a 'super' to be called.