nuqs[0] is a great (React) library for managing state inside of the URL.
URLs are state containers
31–40 of 218 posts
Re: URLs are state containers
#32When 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 stuff that can be updated client side? (a checkbox that's by default checked and you uncheck it, for instance)
Re: URLs are state containers
#33It's fast becoming a lost art (alongside ensuring the text can be read by the 10% of the male population that is colour blind). It's one thing to coach a junior dev on implementing it properly into a Nextjs app (or whatever is trendy at the time), but quite another to have to explain this stuff to a Product Manager. If you're going to spend copious amounts of time with a designer to make sure the site is pixel perfect visually you should also have time to get your URLs right.
Re: URLs are state containers
#34The amount of state that early video games stored in like 256 bytes of ram was actually quite impressive. I bet with some creativity one could do similarly for a web app. Just don’t use gzipped b64-encoded json as your in-url state store!
My 8-bit IDE lets you share your ROM as a lzg/b64-encoded URL. Things get dicey when you go above 2000 characters or so.
Re: URLs are state containers
#35This is a risky idea, actually — at least in its fully expanded form.
Sure, in the prismjs.com case, I have one of those comments in my code too. But I expect it to break one day.
If a site is a content generator and essentially idempotent for a given set of parameters, and you think the developer has a long-term commitment to the URL parameters, then it's a reasonable strategy (and they should probably formalise it).
Perhaps you implement an explicit "save to URL" in that case.
But generally speaking, we eliminated complex variable state from URLs for good reasons to do with state leakage: logged-in or identifying state ending up in search results and forwarded emails, leaking out in referrer logs and all that stuff.
It would be wiser to assume that the complete list of possible ways that user- or session-identifying state in a URL could leak has not yet been written, and to use volatile non-URL-based state until you are sure you're talking about something non-volatile.
Search keywords: obviously. Seach result filters? yeah. Sort direction: probably. Tags? ehh, as soon as you see [] in a URL it's probably bad code: think carefully about how you represent tags. Presentation customisation? No. A backlink? no.
It's also wiser to assume people want to hack on URLs and cut bits out, to reduce them to the bit they actually want to share.
So you should keep truly persistent, identifying aspects in the path, and at least try not to merge trivial/ephemeral state into the path when it can be left in the query string.
Re: URLs are state containers
#36When 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.
Re: URLs are state containers
#37When 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…
To save the url length, why not hash all possible states and have the value of the variable in the query string refer to that?
Re: URLs are state containers
#38When 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…
To save the url length, why not hash all possible states and have the value of the variable in the query string refer to that?
Because a hash is by definition a one-way mapping, so then you'd have to keep a map of the reverse mapping hash -> state, which obviously gets impractical with state such as page index or search terms. Better just make two-way "compression" mapping
Re: URLs are state containers
#39To fully describe client side state you also need to look at DOM and cookies. The server can effectively see this stuff too (e.g., during form post). I design my SSR apps so that as much state as possible lives in the server. I find the session cookie to be far more critical than the URL. I could build most of my apps to be URL agnostic if I really wanted to. The current state of the client (as the server sees it) ca…
This entire article is an argument against your approach here, and you're not really addressing any of its points.
Basically, your approach is easier to code, and worse to use. Bookmarks, multiple tabs, the back button, sharing URLs with others, it all becomes harder for users to do with your design. I mean feel free, because with many tech stacks it is indeed easier, but don't pretend it's not a tradeoff. It's easier and worse.
Re: URLs are state containers
#40When 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…
To save the url length, why not hash all possible states and have the value of the variable in the query string refer to that?
This is a viable solution, but as the article mentions, you lose intent and readability (e.g. seeing a query parameter for “product=laptop” vs. “state=XBE4eHgU”). And in general, it’s unlikely you’ll run into issues with URL length. Two to eight thousand characters is a lot!