I agree, and this reminds me: I really wish there was better URL (and DNS) literacy amongst the mainstream 'digitally literate'. It would help reduce risk of phishing attacks, allow people to observe and control state meaningful to their experience (e.g. knowing what the '?t=_' does in youtube), trimming of personal info like tracking params (e.g. utm_) before sharing, understanding https/padlock doesn't mean trusted…
URLs are state containers
61–70 of 218 posts
Re: URLs are state containers
#62Re: URLs are state containers
#63Earlier quoted context omitted.
JS does have features for editing the history, but it's a trade-off of not polluting the history too much while still letting the user navigate back and forth
I'm glad to see that prismjs site mentioned by the blog is doing the right thing - when it updates the URL, it replaces the current history item.
Both approaches (appending/rewriting) have their uses, the tricky part is using the right thing for the right action, fuck up either and the experience is abysmal.
Re: URLs are state containers
#64Re: URLs are state containers
#65A challenge for this is that the URL is the most visible part of an HTTP request but there are many other submerged parts that are not available as UI yet are significant to the http response composition.
Additionally, aside from very basic protocol, domain, and path, the URL is a very not human friendly UI for composing the state.
Re: URLs are state containers
#66Not quite. As the L in URL says, it is the locator or address of the state. The S in REST implies the same, indicating states as the content, not path to it.
Re: URLs are state containers
#67When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…
I can understand "shareable" state (scroll position), but _as much as possible_ seems like overkill. Why not just use localStorage?
So that I can operate two windows/tabs of the same site in parallel without them stealing each other’s scroll position. In addition, the second window/tab may have originated from duplicating the first one.
Re: URLs are state containers
#68When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…
I completely agree. In fact, I believe URL design should be part of UX design, and although I've worked with 30+ UX designers, I've never once received guidance on URLs.
Re: URLs are state containers
#69Not quite. As the L in URL says, it is the locator or address of the state. The S in REST implies the same, indicating states as the content, not path to it.
State is just your location in state space.
Re: URLs are state containers
#70I actually implemented a comment system where users just pick any arbitrary URL on the domain, ie, http://exampledomain.com/, and append /@say/ to the URL along with their comment so the URL is the UI. An example comment would be typed in the URL bar like,
http://exampledomain.com/somefolder/somepage.html/@say/Hey! Cool somepage. - Me
And then my perl script tailing the webserver log file sees the line and and adds the comment "Hey! Cool somepage. - Me" to the .html file on disk for comments.