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

71–80 of 218 posts

Re: URLs are state containers

#71

Post by LegionMammal978 »

embedding-shape wrote: post #63
orphea wrote: post #59

Earlier quoted context omitted.

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.

Does that handle back button correctly? Nothing more annoying that sites/apps that overwrites the history incorrectly, so when you press the back button it goes to the entry before you entered the website/app, rather than back into what you were doing in the website/app. Both approaches (appending/rewriting) have their uses, the tricky part is using the right thing for the right action, fuck up either and the experie…

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.

Re: URLs are state containers

#72

Post by zkmon »

Scarblac wrote: post #3
zkmon wrote: post #2

Not 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.

But from the viewpoint of a web app where you navigate between different (versions of) pages, the state of that app can be the address of the currently displayed page.

It's the state of your browser, not the app. App could be serving different pages to different clients at the same time.

Re: URLs are state containers

#73

Post by embedding-shape »

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

Earlier quoted context omitted.

Does that handle back button correctly? Nothing more annoying that sites/apps that overwrites the history incorrectly, so when you press the back button it goes to the entry before you entered the website/app, rather than back into what you were doing in the website/app. Both approaches (appending/rewriting) have their uses, the tricky part is using the right thing for the right action, fuck up either and the experie…

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 used, nor how the history is being treated. Either they don't have time, don't have the power to send back tasks to product, simply don't care or just don't think of it. They happily carry along creating whatever URIs make sense to them.

No one is responsible for URLs, no one considers that part of UX and design, so no one ends up thinking about it, people implement things as they feel is right, without having a full overview over how things are supposed to fit together.

Anyways, that's just based on my experience, I'm sure there are other holes in the process that also exacerbates the issue.

Re: URLs are state containers

#74

Post by tomtomistaken »

vbezhenar wrote: post #4

When the system evolves, you need to change things. State structure also evolves and you will refactor and rework it. You'll rename things, move fields around. URL is considered a permanent string. You can break it, but that's a bad thing. So keeping state in the URL will constrain you from evolving your system. That's bad thing. I think, that it's more appropriate to treat URL like a protocol. You can encode some st…

You can always do versioning.

Re: URLs are state containers

#76

Post by hamdingers »

thijsvandien wrote: post #36
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…

While I like this approach as well, these URLs ending up in the browser history isn’t ideal. Autocomplete when just trying to go to the site causes some undesired state every now and then. Maybe query params offer an advantage over paths here.

Browser autocomplete behavior is reliably incorrect and infuriating either way, so it's not a good reason to avoid the utility of having bookmarkable/sharable urls.

Re: URLs are state containers

#77

Post by tsimionescu »

cluckindan wrote: post #19
btown wrote: post #14

Earlier quoted context omitted.

I mean, at the end of the day it is a cerealization format…

Jokes aside, the crux of HATEOAS is having a dumb frontend which just displays content and links from backend responses. All logic is on the server side. It is more like a terminal connection than a browser based application.

Not at all. HATEOAS is about defining data formats that the client and server agree on ahead of time.

Browsers running Javascript referenced from HTML is a perfect example of HATEOAS, for example. browsers and web server creators agreed on the semantics of these two data formats, and now any browser in the world can talk to any web server in the world and display what was intended to be displayed to the user.

If the web design hadn't been HATEOAS, you'd need server specific code in your browser, like AOL had a long time ago, where your browser would know how to look up specific parts of the AOL site and display them. This is also how most client apps are developed, since both the client and the server are controlled by the same entity, and there is no problem in hardcoding URLs in the client.

Re: URLs are state containers

#78

Post by MPSimmons »

jraph wrote: post #32
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 make sure that as much state as possible is saved in a URL Do you have advice on how to achieve this (for purely client-side stuff)? - How do you represent the state? (a list of key=value pair after the hash?) - How do you make sure it stays in sync? -- do you parse the hash part in JS to restore some stuff on page load and when the URL changes? - How do you manage previous / next? - How do you manage server-side…

One example I think is super interesting is the NWS Radar site, https://radar.weather.gov/

If you go there, that's the URL you get. However, if you do anything with the map, your URL changes to something like

https://radar.weather.gov/?settings=v1_eyJhZ2VuZGEiOnsiaWQiO...

Which, if you take the base64 encoded string, strip off the control characters, pad it out to a valid base64 string, you get

"eyJhZ2VuZGEiOnsiaWQiOm51bGwsImNlbnRlciI6Wy0xMTUuOTI1LDM2LjAwNl0sImxvY2F0aW9uIjpudWxsLCJ6b29tIjo2LjM1MzMzMzMzMzMzMzMzMzV9LCJhbmltYXRpbmciOmZhbHNlLCJiYXNlIjoic3RhbmRhcmQiLCJhcnRjYyI6ZmFsc2UsImNvdW50eSI6ZmFsc2UsImN3YSI6ZmFsc2UsInJmYyI6ZmFsc2UsInN0YXRlIjpmYWxzZSwibWVudSI6dHJ1ZSwic2hvcnRGdXNlZE9ubHkiOmZhbHNlLCJvcGFjaXR5Ijp7ImFsZXJ0cyI6MC44LCJsb2NhbCI6MC42LCJsb2NhbFN0YXRpb25zIjowLjgsIm5hdGlvbmFsIjowLjZ9fQ==", which decodes into:

{"agenda":{"id":null,"center":[-115.925,36.006],"location":null,"zoom":6.3533333333333335},"animating":false,"base":"standard","artcc":false,"county":false,"cwa":false,"rfc":false,"state":false,"menu":true,"shortFusedOnly":false,"opacity":{"alerts":0.8,"local":0.6,"localStations":0.8,"national":0.6}}

I only know this because I've spent a ton of time working with the NWS data - I'm founding a company that's working on bringing live local weather news to every community that needs it - https://www.lwnn.news/

Re: URLs are state containers

#79

Post by yoavm »

zkmon wrote: post #75

You are either changing the meaning of "state", or probably unaware of what it means. To start with, state of what? app (http server) or the http client?

I think the author is referring to the state of the form.
Post reply on HN