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

101–110 of 218 posts

Re: URLs are state containers

#101

Post by SoftTalker »

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…

Yeah I use a web app regularly for work where they have implemented their own "back" button in the app. The app maintains its own state and history so the browser back button is totally broken.

The problem here is that they've implemented an application navigation feature with the same name as a browser navigation feature. As a user, you know you need to click "Back" and your brain has that wired to click the broswer back button.

Very annoying.

Having "Refresh" break things is (to me) a little more tolerable. I have the mental association of "refresh" as "start over" and so I'm less annoyed when that takes me back to some kind of front page in the app.

Re: URLs are state containers

#102

Post by SoftTalker »

hamdingers wrote: post #76
thijsvandien wrote: post #36

Earlier quoted context omitted.

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.

Yeah it's an annoyance more than it helps. I always disable it.

Re: URLs are state containers

#103

Post by Ayesh »

SoftTalker wrote: post #97

Modern browsers have an "open clean link" feature that strips all the query parameters (everything after the '?' character in the URL). This is because many sites cram the URL full of tracking IDs, and people like to browse without that. So if you are embedding state in your URL, you probably want to be sure that your application does something sane if the browser strips all of that out.

> Everything after the '?' character.

It only strips known tracking parameters b(like those utm_ query params). It does not remove all parameters; if that's the case, YouTube video links will stop working.

Re: URLs are state containers

#104

Post by pyrolistical »

mrexroad wrote: post #68
fittom wrote: post #51

Earlier quoted context omitted.

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.

As a UX designer that always gives guidance on URL design/strategy, I’ll say it’s not always well received. I’ve run into more than a few engineering or PM teams who feel that’s not w/in scope of design.

As a dev mentor one of my first lesson is what everybody has in common is design.

We all are trying to understand a problem and trying to figure out the best solution.

How each role approaches this has some low level specializations but high level learnings can be shared.

Re: URLs are state containers

#105

Post by Ayesh »

jarofgreen wrote: post #90

Also to consider: bot traffic and SEO. Depending on which mechanism you use to construct your state URLs they will see them as different pages, so you may end up with a lot of extra traffic and/or odd SEO side effects. For SEO at least there are clear directives you can set that help. Not saying you shouldn't do this - just things to consider.

Canonical URLs come to the rescue.

Re: URLs are state containers

#106

Post by moritzwarhier »

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.

Nothing weird about it, you see people arguing right here whether a site should add a new history entry when a filter is set.

Interacting with the URL from JS within the page load cycle is inherently complex.

For what it's worth, I'd also argue that the right behavior here is to replace.

But that of course also means that now the URL on the history stack for this particular view will always have the filter in it (as opposed to an initial visit without having touched anything).

Of course the author's case is the good/special one where they already visited the site with a filter in the URL.

But when you might be interested in using the view/page with multiple queries/filters/paramerers, it might also be unexpected: for example, developers not having a dedicated search results page and instead updating the query parameters of the current URL.

Also, from the history APIs perspective, path and query parameters are interchangeable as long as the origin matches, but user expectations (and server behavior) might assign them different roles.

Still, we're commenting on a site where the main view parameter (item ID, including submission pages) is a query parameter. So this distinction is pretty arbitrary.

And the most extreme case of misusing pushState (instead if replace) are sites where each keystroke in some typeahead filter creates a new history entry.

All of this doesn't even touch the basic requirement that is most important and addressed in the article: being able to refresh the page without losing state and being able to bookmark things.

Manually implementing stuff like this on top of a basic routing functionality (which should use pushState) in an SPA is complex very quickly.

Re: URLs are state containers

#107

Post by asielen »

MPSimmons wrote: post #78
jraph wrote: post #32

Earlier quoted context omitted.

> 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 "eyJhZ2VuZGEiOnsiaWQiO…

In this case, why encode the string instead of just having the options as plain text parameters?

Re: URLs are state containers

#108

Post by aatd86 »

Finishing building a framework at the moment. I'd rather say that they are state descriptors... They don't contain all the state. But they are some kind of hashkey that allow to retrieve application state. "Hypertext as the engine of application state."

Re: URLs are state containers

#109

Post by noir_lord »

SoftTalker wrote: post #102
hamdingers wrote: post #76

Earlier quoted context omitted.

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.

Yeah it's an annoyance more than it helps. I always disable it.

I do as well - it's just irritating.

Same with search ahead.

Re: URLs are state containers

#110

Post by apitman »

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, sometimes (though rarely) down to the scroll position.

If your page is server-rendered, you get saved scroll position on refresh for free. One of many ways using JS for everything can subtly break things.

Post reply on HN