Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URLs are state containers

alfy.blog

Post reply on HN
Print view View original

191–200 of 218 posts

Re: URLs are state containers

#191

Post by _heimdall »

embedding-shape wrote: post #73
LegionMammal978 wrote: post #71

Earlier quoted context omitted.

It's pretty weird, my impression is that the APIs are flexible enough to implement most sane behaviors, but websites keep managing to mess it all up. Perhaps it's just one of those things that no one bothers re-testing as the codebase changes.

In my experience, the problem is two-fold. First product managers/owners don't consider the URIs, so it ends up not being specified. They say "We should have a page when user clicks X, and then on that page, user can open up modal Y", but none of it is specified in terms of what happens with the URIs and history. Then a developer gets the task to create this, and they too don't push back on what exact URIs are being…

Web developers should make it a habit to ask/require URL structures be part of the spec.

I've had people be surprised by the request because its something they don't usually consider, but I've never had anyone actually push back on it.

Re: URLs are state containers

#192

Post by klntsky »

I wish there was a way to have undo/redo like when using pushState, but without polluting history. There is no separate "serializable state" API that is not tied to a URL. I could use LocalStorage, but I want to have multiple states in different tabs, persistent across reloads. Maybe storing "tab IDs" in URLs and state in LocalStorage is a good idea.

Re: URLs are state containers

#193

Post by jillesvangurp »

nubinetwork wrote: post #187

URLs are user supplied. You can't trust user data in 95% of cases. Storing stuff belongs in a database or a cookie.

That's true for any content or request coming from the user. If it's not signed by a trusted party, you should not trust it and instead validate whatever you receive. It doesn't matter whether a client side database, a cookie, a file, or indeed the url was used.

Urls are kind of convenient for a lot of things like form parameters, #link into an app or page, etc. That's state. Adding a bit more state via json in a parameter or whatever is about as old as the web is. Mostly, url length restrictions are still a bit of a problem but you need really long urls these days to hit those with most browsers. But aside from that, it's just another way to store stuff between requests.

Re: URLs are state containers

#194

Post by cassepipe »

latexr wrote: post #186
jorl17 wrote: post #24

When 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 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 it doesn't make sense. I do dislike those cases. But I also dislike being two-thirds through a video or page, thinking “I’ve got to share this with , it’s…

I understand the inconvenience to have to leave a keyboard-driven workflow but I think the Share button --> Copy link are common enough now that it shouldn't be an issue. I know firefox also has "Copy clean link" if you right-click on the urlbar.

I did not find an extension that does just that but it should be trivial to create one and assign a shortcut to it.

Re: URLs are state containers

#195

Post by liampulles »

mexicocitinluez wrote: post #185
liampulles wrote: post #184

You are still thinking of the web as being a hyperlinked collection of information serving the betterment of human knowledge, rather than a set of SPAs where you through trial and error try and get whatever AI enabled product you are now forced to use to do what you ask.

Nothing of what you said has anything to do with storing state in the URL.

My meaning is that good URL design was more prevalent when people consciously included more links to other websites within their own website. This is because making well formed URLs is of importance if you think people are actually going to take that URL and link it somewhere. The rest of my comment is snark around SPAs, because I think they conversely do not often do URL design well (manipulating the DOM off the back of JSON REST API calls, rather than guiding the state of the page off the URL, allows one not to have to think about it as much as one should).

I hope that clears things up.

Re: URLs are state containers

#196

Post by latexr »

cassepipe wrote: post #194
latexr wrote: post #186

Earlier quoted context omitted.

> 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 it doesn't make sense. I do dislike those cases. But I also dislike being two-thirds through a video or page, thinking “I’ve got to share this with , it’s…

I understand the inconvenience to have to leave a keyboard-driven workflow but I think the Share button --> Copy link are common enough now that it shouldn't be an issue. I know firefox also has "Copy clean link" if you right-click on the urlbar. I did not find an extension that does just that but it should be trivial to create one and assign a shortcut to it.

Whenever I try that flow, it either copies the link with the extra details or it screws up the link entirely (e.g. removing the `?v=` from a YouTube link). In other words, it’s extra work for worse results.

Re: URLs are state containers

#197

Post by thrance »

noctune wrote: post #168
padolsey wrote: post #8

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…

It doesn't help that URLs are badly designed. It's a mix of left- and rightmost significant notation, so the most significant part is in the middle of the URL and hard to spot for someone non-technical. Really we should be going to com.ycombinator.news/item?id=45789474 instead.

Damn, now I want something we'll never have.

Re: URLs are state containers

#198

Post by layer8 »

zkmon wrote: post #98
layer8 wrote: post #96

Earlier quoted context omitted.

Not every location represents a state, but every state can be considered a location. If you want to argue against the use of URLs to represent state, I would concentrate on the “R” (resource) aspect.

I think you are talking about client's navigational state. The original title of this post was "app state ...". Still it is not clear about state of what. Navigational state need not be confused with app state. Also talking about "state" as in "state machine" etc used to sound pretty academic with obscure meaning of the word "state". When someone says "state machine" they are basically saying "I'm a PhD and you are n…

My point was a linguistic-conceptual one, that a location fully describing a state is not a contradiction in terms, and hence it’s not necessarily a misuse of the “URL” concept regarding the “locator” aspect. Navigational versus application state is irrelevant to that argument.
Post reply on HN