121–130 of 218 posts
Why?
I get it if we're talking about a size that flirts with browser limitations. But other than that I see absolutely no problem with this. In fact it makes me think the author is actually underrating the use-case of URL's as state containers.
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…
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 the…
nuqs[0] is a great (React) library for managing state inside of the URL. [0] https://nuqs.dev/
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
https://rssrdr.com/?rss=raw.githubusercontent.com/Roald87/Ha...
Earlier quoted context omitted.
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.
In my experience, the problem is two-fold. First product managers/owners don't consider the URIs, so it ends up not being specified. They say "We should have a page when user clicks X, and then on that page, user can open up modal Y", but none of it is specified in terms of what happens with the URIs and history. Then a developer gets the task to create this, and they too don't push back on what exact URIs are being…
That said, I've also worked with some developers that didn't like intruding on their turf, so to speak. Though I've also worked with others that were more than happy to collaborate and very proactive about these sorts of things.
Furthermore, as a UX designer this is the sort of topic that we're unlikely to be able to meaningfully discuss with PMs and other stakeholders as it's completely non-visual and often trying to bring this up with them and discuss it ends up feeling like pulling teeth and them wondering why we're even spending time on it. So usually it just ended up being a discussion between me and the developers with no PM oversight.
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.