-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[BUGFIX beta] Check that handler exists before triggering event #14087
Conversation
LGTM. I think I'm fine merging without an additional test. |
@trentmwillis could you please prefix the commit message with |
The other approach we considered was a promise chain to guarantee that the handler was already loaded, but that was breaking everything in Ember and doesn't actually change the behavior here. |
b961301
to
3e9899a
Compare
@dgeb updated. I'm always unsure of what to prefix my commits with. |
@dgeb I have doubts about this not being tested. |
@krisselden That's fair. Let's hold off on merging until we can figure out the best way to test this. |
This is necessary for lazily-loaded routes where the handler is not available synchronously. This includes events like loading and queryParamsDidChange which trigger synchronously after starting a transition, in those cases we should by-pass handlers that are not yet loaded.
3e9899a
to
ce72c7e
Compare
Added two unit tests, let me know if you think more is needed. Opted for unit tests since the |
These tests seem good for the changes being made here. I would like to make sure that we get at least one higher level acceptance style test that emulates what we are actually doing in ember-engines WRT to |
@rwjblue I agree. Unfortunately, having The only reason this PR is happening right now is because it seemed to make more sense than trying to monkeypatch it into the addon. |
@trentmwillis - Would you mind making a followup issue here to add an acceptance test for |
Opened an issue to follow up. |
This is necessary for lazily-loaded routes where the handler is not
available synchronously. This includes events like loading and
queryParamsDidChange which trigger synchronously after starting a
transition, in those cases we should by-pass handlers that are not
yet loaded.
cc/ @rwjblue @nathanhammond @dgeb
Note: I feel like I should add a test for this, but I feel like it makes more
sense to just test this in the ember-engines repo, since this code path is
impossible to hit normally.