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

91–100 of 218 posts

Re: URLs are state containers

#91

Post by jFriedensreich »

Hot module replacement masks a lot of annoyances for end users. Yes its more instantaneous than reloading a page and relying on urls for all of the state and I am not advocating hard for abolishing HMR anymore, but it would be nice if we still used way more url state than currently the case. Browsers will also hibernate tabs to varying degrees, server sessions expire all the time, things are not shareable. The only thing that works as users expect is url state. One thing i absolutely hate about ios apps is how every state is lost if i just have the app in the background for a few seconds, this even applies to major apps like youtube, google maps, many email clients etc. Why do we live in this stupid world were things are not getting better, just because someone made things more convenient for developers?

PS: and i curse the day the social media brainwashed marketing freak coined the term "deep link" to mean just a normal link as its supposed to work.

Re: URLs are state containers

#92

Post by embedding-shape »

macNchz wrote: post #89
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 definitely possible to make a really stellar experience, but that winds up being the exception. The URL and history state are sort of “invisible” elements of the user experience but require thoughtful care and attention to what the user expects/wants at each step, a level of attention which is already a rarity in web development even in the most visible parts of a page…so frequently the history/back button stuff…

Yeah, in my experience you only get great stuff when both product and engineering has equal care for the final experience. If either parties lack care, you'll miss stuff, particularly things that are "invisible" as you say.

Re: URLs are state containers

#93

Post by mejutoco »

layer8 wrote: post #67
MattDaEskimo wrote: post #43

Earlier quoted context omitted.

I can understand "shareable" state (scroll position), but _as much as possible_ seems like overkill. Why not just use localStorage?

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

You could work around that if needed with a unique id per tab (I was curious myself)

https://stackoverflow.com/questions/11896160/any-way-to-iden...

Re: URLs are state containers

#94

Post by layer8 »

mejutoco wrote: post #93
layer8 wrote: post #67

Earlier quoted context omitted.

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

You could work around that if needed with a unique id per tab (I was curious myself) https://stackoverflow.com/questions/11896160/any-way-to-iden...

Yes, but how do you garbage-collect the stored per-tab state from the local storage? Note that it’s not just per tab, but per history entry of the tab. (When the user goes back, they want the respective state to be restored, and again when going forward in reverse.) Furthermore, with browser features like “reopen closed tab”. Better let the browser manage the state implicitly by managing the URLs.

Re: URLs are state containers

#95

Post by makeitdouble »

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.

Th web has evolved a lot, as users we're seeing an incredible amount of UX behaviors which makes any single action take different semantics depending on context.

When on mobile in particular, there's many cases where going back to the page's initial state is just a PITA the regular way, and refreshing the page is the fastest and cleanest action.

Some implementations of infinite scroll won't get you to the content top in any simple way. Some sites are a PITA regarding filtering and ordering, and you're stuck with some of the choices that are inside collapsible blocks you don't even remember where they were. And there's myriads of other situation where you just want the current page in anew and blank state.

The more you keep in the url, the more resetting the UX is a chore. Sometimes just refreshing is enough, sometimes cleaning the URL is necessary, sometimes you need to go back to the top and navigate back to the page you were on. And those are situations where the user is already in frustration over some other UX issue, so needing additional efforts just to reset is a adding insult to injury IMHO.

Re: URLs are state containers

#96

Post by layer8 »

zkmon wrote: post #69
layer8 wrote: post #66

Earlier quoted context omitted.

State is just your location in state space.

An address book is not "state space". The country, land and things are the state.

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.

Re: URLs are state containers

#97

Post by SoftTalker »

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.

Re: URLs are state containers

#98

Post by zkmon »

layer8 wrote: post #96
zkmon wrote: post #69

Earlier quoted context omitted.

An address book is not "state space". The country, land and things are the state.

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 not". There are simpler and more crisp ways to convey things rather than via obscurity.

Re: URLs are state containers

#99

Post by mrbonner »

I believe draw.io achieves complete state persistence solely through the URL. This allows you to effortlessly share your diagrams with others by simply providing a link that contains an embedded Base64-encoded string representing the diagram’s data. However, I’m uncertain whether this approach would qualify as a “state container” according to the definition presented in the article.
Post reply on HN