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

131–140 of 218 posts

Re: URLs are state containers

#131

Post by pests »

endless1234 wrote: post #115
apitman wrote: post #110

Earlier quoted context omitted.

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

Still leaves the problem of not being able to simply send the current URL to someone else and know they'll see the same thing. Of course anchors can solve this, but not automatically

Chrome (at least?) solves this via Text Fragments[0] which are a pure client side thing and requires no server or site support.

This URI for example:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Links to an instance of "The Referer" narrowed down via a start prefix ("downgrade:") and end suffix ("to origins").

These are used across Google I believe so many have probably seen them.

[0] https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...

Re: URLs are state containers

#132

Post by MattDaEskimo »

layer8 wrote: post #94
mejutoco wrote: post #93

Earlier quoted context omitted.

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.

Scroll position is _kind of_ fine. Typically I can link the ID in the URL as "state".

I was referring to mostly everything else

Re: URLs are state containers

#133

Post by XCSme »

> #/dashboard - Single-page app routing (though it’s rarely used these days)

I actually use that for my self-hosted app, because hash routing doesn't require .htaccess or other URL rewriting functionality server-side. So yes, it's not ideal, but you don't fully control the deployment environment, it's better to reduce as much as you can the requirements.

Re: URLs are state containers

#134

Post by nextaccountic »

o11c wrote: post #129
apitman wrote: post #110

Earlier quoted context omitted.

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

Even with JS, if it is classical synchronous JS it is much better than the modern blind push for async JS, which causes the browser to try to restore the position before the JS has actually created the content.

isn't there a way to instruct the browser to restore the position only after certain async thing?

Re: URLs are state containers

#135

Post by nextaccountic »

divan wrote: post #111
apitman wrote: post #110

Earlier quoted context omitted.

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

Also reminder that "refresh" is just a code word for "restart (and often redownload) the whole bloody app". It's funny how in web-world people so used to "refreshing" the apps and assume that it's a normal functionality (and not failure mode).

The web is similar to android, and unlike desktop apps, in that restarting the whole thing is meant to not lose (much) state

Actually it would be amazing if desktop applications were like this too, and we had a separate way to go back to the initial screen

Re: URLs are state containers

#136

Post by divan »

nextaccountic wrote: post #135
divan wrote: post #111

Earlier quoted context omitted.

Also reminder that "refresh" is just a code word for "restart (and often redownload) the whole bloody app". It's funny how in web-world people so used to "refreshing" the apps and assume that it's a normal functionality (and not failure mode).

The web is similar to android, and unlike desktop apps, in that restarting the whole thing is meant to not lose (much) state Actually it would be amazing if desktop applications were like this too, and we had a separate way to go back to the initial screen

Restoring state is just one of the features, that can be implemented in any app if needed, with all that baggage that comes with a feature – testing, maintaining, etc. It's just if desktop app becomes so broken/unresponsive, that the only way is to restart it – we consider it a bad experience and bad software. On web "restarting the app" is a normal daily activity when something goes wrong with state/layout/fields/forms, etc.

Re: URLs are state containers

#137

Post by Dwedit »

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.

My personal take would be if it takes you to what's basically another page (such as the entire page being rewritten), then involve browser history.

Re: URLs are state containers

#138

Post by yawaramin »

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…

The OP gives great guidance on these questions.

Re: URLs are state containers

#139

Post by nextaccountic »

divan wrote: post #136
nextaccountic wrote: post #135

Earlier quoted context omitted.

The web is similar to android, and unlike desktop apps, in that restarting the whole thing is meant to not lose (much) state Actually it would be amazing if desktop applications were like this too, and we had a separate way to go back to the initial screen

Restoring state is just one of the features, that can be implemented in any app if needed, with all that baggage that comes with a feature – testing, maintaining, etc. It's just if desktop app becomes so broken/unresponsive, that the only way is to restart it – we consider it a bad experience and bad software. On web "restarting the app" is a normal daily activity when something goes wrong with state/layout/fields/fo…

Most desktops apps are buggy enough to occasionally require restarts or even crash. I don't currently use any program that never crashed on me. On the web "restarting the app" is seamless and not imply anything wrong happened. It's like the Erlang approach to errors, but on steroids

The trouble with leaving restoring state to the application do as they wish is that most of times they will get it wrong. Also most of them don't do any of this and will never do. Good defaults matter

Re: URLs are state containers

#140

Post by callumgare »

dzhar11 wrote: post #125

Recommendation: https://github.com/Nanonid/rison Super old but still a very functional library for saving state as JSON in the URL, but without all the usual JSON clutter. I first saw it used in Elastic's Kibana. I used it on a fancy internal React dashboard project around 2016, and it worked like a charm. Sample: http://example.com/service?query=q:'*',start:10,count:10

Thank you!! There’s a tone of projects where I’ve wanted something like that. I’ve previously cobbling together something ad hoc myself but this looks way more thought out and (slightly) more standard than me making up my own thing.
Post reply on HN