A few years ago, I worked on an app where some of the state was kept in the session and some was on the url as GET params. We ran into an issue where some browsers would only accept urls that were less than 1024 chars long. Is that still an issue today?
How to store your app's entire state in the url
131–140 of 416 posts
Re: How to store your app's entire state in the url
#132Earlier quoted context omitted.
[flagged]
I did once and was told off for adding noise to the discussion by someone who didn't see the irony of their complaint also adding to the noise.
If a one-time correction has its desired impact, the small addition to the noise reduces future noise.
Re: How to store your app's entire state in the url
#133Earlier quoted context omitted.
[flagged]
I did once and was told off for adding noise to the discussion by someone who didn't see the irony of their complaint also adding to the noise.
Two chemists walk into a bar. The first says “I’ll take a glass of H2O.” The second says “I’ll take a glass of H2O too.”
Re: How to store your app's entire state in the url
#134App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
Here is it decoded: {"interval":"week","periodicity":1,"timeUnit":null,"candleWidth":4.3486590038314175,"flipped":false,"volumeUnderlay":true,"adj":true,"crosshair":true,"chartType":"line","extended":false,"marketSessions":{},"aggregationType":"ohlc","chartScale":"linear","studies":{" vol undr ":{"type":"vol undr","inputs":{"id":" vol undr ","display":" vol undr "},"outputs":{"Up Volume":"#00b061","Down Volume":"#ff3…
OT, we used to joke about LISP source code contains mostly brackets. Nowadays we literally store, transform and pass around willy nillily
Re: How to store your app's entire state in the url
#135As usual when I see this sort of thing, I have questions around the security needs of the application. Storing all of this information on the client means that the client has to be trusted to not mess with all of this state. If it's important, it needs to be stored and checked server-side.
yep. A coworker introduced a CSRF doing this. I had to point out that you can't just take raw input from a URL and throw it back on the page. Even after I pointed it out and gave a proof-of-concept they still didn't get it.
Re: How to store your app's entire state in the url
#136Base 64 is probably not the best encoding for this, since the URL allows for a wider range of characters. You can be more efficient by using them as well.
Base 64 is fine - he just needs to url-encode the parameter.
Re: How to store your app's entire state in the url
#137App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6... Dear god... this link was real. I thought it was like a joke or something
Genuinely curious to hear why you are so shocked. Long, ugly, user unfriendly urls are really prevalent. Arguments can be made even query params are pretty ugly.. Are urls expected to be a good UX these days? What's the big deal?
Re: How to store your app's entire state in the url
#138Am I alone in thinking it's ridiculous for an editor action to push/pop state in browser history to allow undo/redo? Surely this leads to substantial browser history pollution?
Absolutely agreed. Given how HN can be when complaining about back button breakage (so common that it had to be explicitly banned), I'm surprised so few people are talking about the implications here.
Re: How to store your app's entire state in the url
#139Earlier quoted context omitted.
> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6... Dear god... this link was real. I thought it was like a joke or something
[flagged]
There are. We just have a high bar. I wrote this, but others have also pointed to it: https://news.ycombinator.com/item?id=7609289
Re: How to store your app's entire state in the url
#140Earlier quoted context omitted.
I decoded that, gzipped --best, then re-encoded and got something that's shorter at least H4sIAAAAAAACA7VU3W7TMBS+5ykmcxuNdOlGyd3QmECCIdYWNKYKnSanqVfHNrbTNqoq7QF4Sp6EYyfpaMYtdz7H5/vOz3fsHePSoVmDYCnbIK5YxDQarnKecVezdBAxx0ucSu5YKishIpaBzAV+47lbsnR4mgxHF+dv4jgZJYPh4PV5xBaCa405SxcgLEZsrUTlKXI0AojTmYq8kD90x8woa5fAzcGxBOMmtUaqSnCJVBVuHRLDE2sJZoVujNZyJS1Ld3viLAqDBTjytGi1FBlrCccZiI4RDHmtq3KOHst+P/6iMk8qmRs6eo9rCDovhXOpKxeiOZ…
you could come up with a better compression scheme given that the dict keys and many of the values are probably common across everyone even if they don't repeat multiple times for a given user. a lot of flexibility would be lost though, and you would need to always update the scheme in a backwards-compatible way.
Once you've already given up on human-readability, it probably doesn't much matter how long/gross the result is. Rather than spending effort and adding complexity, just provide a built in URL shortener.