4 ms·
I think I see what this is for, despite the unilluminating site. Storing state in the URL is a good idea - it lets your users bookmark and share links to your a
by AndrewStephens 9y ago
I think I see what this is for, despite the unilluminating site. Storing state in the URL is a good idea - it lets your users bookmark and share links to your application's state.
I have a couple of questions though:
When I have done this in the past, I have used the url fragment to store the state, i.e.: https://sheep.horse/tagcloud.html#computing https://sheep.horse/tagcloud.html#computing . This works even with static sites because the browser doesn't send the fragment (everything past the # symbol) to the server.
By encoding state in the path of the URL, you require server support. I guess the flip side of that is that your site can continue to work without js support.
I notice that your demo and docs don't mention anything about manipulating the browser's history to allow the user to move to previous states using the back button. That can be a pretty useful thing to provide.
- floatingatoll 9y agoFragments are worse than described here. Fragments are incompatible with redirects. Not only does the browser not send them, but any server-side redirects will either require active-JS redirects to capture and redirect the fragment, or strip the fragment as inappropriate/pointless, or if you're very lucky, maintain it somehow through the redirect. Do not use fragments for any critical function without vetting your entire workflow and all servers and useragents in your request/response path.
- AndrewStephens 9y agoWhat you say is absolutely true, and I agree. But I also subscribe to the URLs-are-user-interface school of thought and think that implementing redirects to change your UI requires careful thought. I'll admit that sometimes it is unavoidable as applications change over time. Maintaining state in the path, query parameters, or fragment are all techniques that can work, but each comes with disadvantages. I wonder if anyone has been mad enough to maintain state in subdomains: https://accnumber18573.color-yellow.example.com/ https://accnumber18573.color-yellow.example.com/
- madmaniak 9y agoYou 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.