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

111–120 of 218 posts

Re: URLs are state containers

#111

Post by divan »

apitman wrote: post #110
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.

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

Re: URLs are state containers

#112

Post by SoftTalker »

Ayesh wrote: post #103
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.

Hm, I didn't know that. Seems very easy to game then, just change your tracking parameter name to one that the browser doesn't strip.

Re: URLs are state containers

#113

Post by qdotme »

asielen wrote: post #107
MPSimmons wrote: post #78

Earlier quoted context omitted.

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?

Nesting, mostly (having used that trick a lot, though I usually sign that record if originating from server).

I've almost entirely moved to Rust/WASM for browser logic, and I just use serde crate to produce compact representation of the record, but I've seen protobufs used as well.

Otherwise you end up with parsing monsters like ?actions[3].replay__timestamp[0]=0.444 vs {"actions": [,,,{"replay":{"timestamp":[0.444, 0.888]}]}

Re: URLs are state containers

#114

Post by smrtinsert »

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…

Url state should be descriptive not prescriptive. Either way it is important. Unfortunately my experience on several teams is that businesses never care about stuff like this but users do.

Re: URLs are state containers

#115

Post by endless1234 »

apitman wrote: post #110
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.

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

Re: URLs are state containers

#116

Post by phillipseamore »

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.

sessionStorage should treat the windows/tabs as separate

Re: URLs are state containers

#118

Post by jarofgreen »

Ayesh wrote: post #105
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.

Only for SEO - they don't help at all with aggressive AI scraper bots.

Re: URLs are state containers

#119

Post by njacobs5074 »

I'm not certain that I agree with this because a URL makes no claims about idempotency or side-effects or many other behaviors that we take for granted when building systems. While it is possible to construct such a system, URLs do not guarantee this.

I think the fundamental issue here is that semantics matter and URLs in isolation don't make strong enough guarantees about them.

I'm all for elegant URL design but they're just one part of the puzzle.

Re: URLs are state containers

#120

Post by simonhamp »

game_the0ry wrote: post #82
simonhamp wrote: post #62

React kid discovers the web

Holding the snark aside for second, I think there is some harsh truth here. Url query params are not popular in the front end developer world for some reason, probably bc the fundamentals of web dev are often skipped in favor of learning leetcode and all the react hooks. Same could be sade for SQL and CSS. I also don't think its a good look that the author is a CTO and is just discovering how useful url query params…

No snark. Genuinely happy. This is progress
Post reply on HN