4 ms·
You have a valid point about # and that it works on static site. I'm aware of that and I'll add this as a feature so you'll be able to choose on init(). Please
by madmaniak 9y ago
You have a valid point about # and that it works on static site. I'm aware of that and I'll add this as a feature so you'll be able to choose on init().
Please explain me the part about back button on example.
- AndrewStephens 9y agoRegarding the back button: take your demo page (youurlh/switcher/) as a perfect example, you can click on the "lights off" link and be taken to yoururl/switcher/night/1. I would expect the back button to take you back to the original switcher url and turn the lights back on, but it doesn't. This is because your write() function uses relaceState() to modify the current url. If you used pushState (like your go() function does) then the browser would correctly maintain history. Now, maintaining a history of the current state is not always the best thing to do. For instance, on your other demo page, the one where you type your name, you probably don't want to push a history item for each key press. I think you should consider offering the option to push local history so that an app developer can decide if it makes sense.
- madmaniak 9y agoOh yes. I was considering that. I've stayed for a while with a convention solution - write and toggle replaces, but go adds to the history. You can build on top of that, but I think it's reasonable now. It manages for you what you want to be in a history. Imagine example with an input which writes on each keyup to the history and going back letter by letter. So when you click on a "link" it goes to the history. If you play with params on a single view it replaces. What do you think?
- AndrewStephens 9y agoSounds like a good rule of thumb but it really depends on the application.