Make push()/update() navigate, and change state interface#54
Conversation
|
This PR cleared up a misunderstanding I had, thanks! And just to clarify, it appears that But I assume it would fire the And should it fire any event if you do |
Closes #36 by moving from appHistoryEntry.state to getState() and setState() methods. This adds the ability to modify the state of non-current entries as a bonus. Solves much of #42 by making push() and update() navigate by default, although it does not yet include the initiator idea. As part of this we simplify update() significantly, since now if you want to change state without performing a navigation, you would use setState(). This makes the URL argument required for it. For symmetry, I removed url from the options for push().
Correct.
Good questions. I think it should not fire currentchange, but probably it should have its own per-entry event. Let me add that. |
|
I'm going to merge this now so I can build more on top of it, but any further reviews after the fact are appreciated! |
|
I'm not sure about I think it creates the same problem that we have today with Further, it means that some part of the application can just clear your state and you don't get any event about it besides currentchange. That also feels bad. |
Closes #36 by moving from appHistoryEntry.state to getState() and setState() methods. This adds the ability to modify the state of non-current entries as a bonus.
Solves much of #42 by making push() and update() navigate by default, although it does not yet include the initiator idea.
As part of this we simplify update() significantly, since now if you want to change state without performing a navigation, you would use setState(). This makes the URL argument required for it. For symmetry, I removed url from the options for push().