Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat(history): Remove event listeners when all apps are destroyed. #3172
feat(history): Remove event listeners when all apps are destroyed. #3172
Changes from 1 commit
037a643
f923d37
6fdde38
db3e347
9d0ba02
97470df
1c90043
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
can't we remove these lines since they are right above? They shouldn't change
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.
we should be able to just check
!this.app
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.
👍 done
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.
There's some new behavior here - previously
transitionTo()
would only get called during app initialization if using html5 or hash history, but now it is being called for abstract mode, too. I did so not because abstract mode needs this, but rather because it simplified the if/else code that existed before and appeared to have no harmful side effects.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.
For this part, it's better to keep the previous behavior because abstract mode cannot always directly transition: e.g. during SSR whereas History and Hash can retrieve the current location on browsers
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 also realized we also need to keep the previous behavior for hash history for the hash event not to fire too early on some browsers
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.
👍 updated
That behavior still exists in this PR, as far as I can tell. HashHistory does not set up listeners until
setupListeners()
is called, andsetupListeners()
is not called until the firsthistory.transitionTo()
finishes up (as shown in the line of code above)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.
The thing that's different here is that now that behavior for HashHistory is also applying to Html5History - beforehand the popstate listener was set up before the first transition, but it now is set up only after the first transition.
I think that new behavior is completely fine. My guess as to why HashHistory needed that special behavior is that hashchange events are fired as a result of programmatic navigation (via
location.hash = '#/new'
), whereas the browser never fires popstate events never for programmatic navigation (viahistory.pushState(state, title, '/new')
)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.
Oops I made the changes related to Abstract History weeks ago but forgot to push!! I commented and said "Updated" even though I didn't push. I have now pushed my changes.