[flagged]
URLs are state containers
21–30 of 218 posts
Re: URLs are state containers
#22To 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…
Maybe I'm misunderstanding what you're saying but applications like this tend to be horrible to use. How do you handle somebody navigating in two tabs at once? What about the back button?
Also bookmarks etc? For example if you have a view where you can have complex filters etc, you may want to bookmark this.
Re: URLs are state containers
#23To 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…
Maybe I'm misunderstanding what you're saying but applications like this tend to be horrible to use. How do you handle somebody navigating in two tabs at once? What about the back button?
I guess they use something like sessionStorage to hold tab specific ids.
But something that can bite you with these solutions if that browsers allow you to duplicate tabs, so you also need some inter-tab mechanisms (like the broadcast API or local storage with polling) to resolve duplicate ids
Re: URLs are state containers
#24When 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 it doesn't make sense.
Developing like this on small teams also tends, in my experience, to lead to better UX, because it makes you much more aware of how much state you're cramming into a view. I'll admit it makes development slower, but I'll take the hit most days.
I've seen some people in this thread comment on how having state in a URL is risky because it then becomes a sort of public API that limits you. While I agree this might be a problem in some scenarios, I think there are many others where that is not the case, as copied URLs tend to be short-lived (bookmarks and "browser history" are an exception), mostly used for refreshing a page (which will later be closed) or for sharing . In the remaining cases, you can always plug in some code to migrate from the old URL to the new URL when loading, which will actually solve the issue if you got there via browser history (won't fix for bookmarks though).
Re: URLs are state containers
#25The 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!
With a custom compression dictionary made against your JSON schema, I would bet you could still pack a surprising amount of data into 256 bytes that way.
Re: URLs are state containers
#26More good content with a bunch of GPT noise added, obvious from patterns like No database. No cookies. No localStorage Themes chosen. Languages selected. Plugins enabled. Which have the pattern of rhetoric but no substance. Clearly the author put significant effort it so why get an LLM to add noise?
Is it really an LMM? It's not like real humans can't write the same style, LLMs have picked up on an existing stylistic tendency. I hate these patterns as much as anyone, and I have noticed them since long before transformers were a thing.
Re: URLs are state containers
#27I really like this approach, and think it should be used more!
In a previous experiment, I created a simple webpage which renders media stored in the URL. This way, it's able to store and render images, audio, and even simple webpages and games. URLs can get quite long, so can store quite a bit of data.
Re: URLs are state containers
#28Sure and file names are state & attribute containers too. A URL is a uniform resource locator. You can hack it, of course, but this is no less kludgy than overloading filename. It is never ceases to amaze me seeing the recylcing of good and bad idea in this field.
Re: URLs are state containers
#29> Browsers and servers impose practical limits on URL length (usually between 2,000 and 8,000 characters) but the reality is more nuanced. As this detailed Stack Overflow answer explains, limits come from a mix of browser behavior, server configurations, CDNs, and even search engine constraints. If you’re bumping against them, it’s a sign you need to rethink your approach.
So what is the reality? The linked StackOverflow answer claims that, as of 2023, it is "under 2000 characters". How much state can you fit into under 2000 characters without resorting to tricks for reducing the number of characters for different parameters? And what would a rethought approach look like?
Re: URLs are state containers
#30Mmm.
Youre doing two things:
1) youre moving state into an arbitrary untrusted easy to modify location.
2) youre allowing users to “deep link” into a page that is deep inside some funnel that may or may not be valid, or even exist at some future point in time, forget skipping the messages/whatever further up.
You probably dont want to do either of those two things.