In other words, tracking
How to store your app's entire state in the url
231–240 of 416 posts
Re: How to store your app's entire state in the url
#232I imagine I'm not the first one to think of this, but a little while back I wrote a toy pastebin-like webpage that stored the code being rendered directly in the URL (with base64 and gzip compression to make it a bit smaller, although it still was quite large by usual standards). My thinking was that rather than having a centralized app for this publicly available, making a small page that could be statically hosted…
Great minds think alike? I just posted about my URL-using pastebin: https://news.ycombinator.com/item?id=34315577
There are quite a few of these apparently. https://topaz.github.io/paste/ (lzma) from the creator of Advent Of Code, and mine: https://dzaima.github.io/paste/ (pako)
Re: How to store your app's entire state in the url
#233App 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…
The possible advantage of the encoding is that it that it can be encrypted and make parameter hacking impossible.
Yeah, why not just base64 encode, shove that into a db with a shorter key? I'm pretty positive this is how tiktok works for sharing videos.
Re: How to store your app's entire state in the url
#234Earlier quoted context omitted.
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
Speaking about LISP and state in the URL, this is how OVH stores the state when you buy a domain from them:
https://www.ovh.com/fr/order/webcloud/?#/webCloud/domain/options?selection=~(domains~(list~(~(name~'somethinghn.com))~options~(~'dnssec)))Re: How to store your app's entire state in the url
#235Re: How to store your app's entire state in the url
#236Great for complex apps in the browser and sharing complex save states!
Bad for ordinary, mundane web applications and sharable URLs!
Like, great for a musical step sequencer in the browser, bad for a website or HTTP service
OTOH, app state on websites of commercial service prodivders might be best represented by a JSON blob anyway.
In something like a checkout process or form submit, of course this doesn't matter much.
But I prefer human-readable URLs wherever possible.
And I implemented a similar pattern once, too.
It's a very interesting approach in intself.
Relevant POJO state tends to be small enough but long lists or resourcrs in a URL are not supported by most servers and not advisable.
Re: How to store your app's entire state in the url
#237App 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…
I decoded that, gzipped --best, then re-encoded and got something that's shorter at least H4sIAAAAAAACA7VU3W7TMBS+5ykmcxuNdOlGyd3QmECCIdYWNKYKnSanqVfHNrbTNqoq7QF4Sp6EYyfpaMYtdz7H5/vOz3fsHePSoVmDYCnbIK5YxDQarnKecVezdBAxx0ucSu5YKishIpaBzAV+47lbsnR4mgxHF+dv4jgZJYPh4PV5xBaCa405SxcgLEZsrUTlKXI0AojTmYq8kD90x8woa5fAzcGxBOMmtUaqSnCJVBVuHRLDE2sJZoVujNZyJS1Ld3viLAqDBTjytGi1FBlrCccZiI4RDHmtq3KOHst+P/6iMk8qmRs6eo9rCDovhXOpKxeiOZ…
[deleted]
Re: How to store your app's entire state in the url
#238Earlier quoted context omitted.
Another reason to not base64 encode is that many URLs with base64 strings will break in iMessage do to strings randomly matching various keywords that iMessage looks for. I think ‘usd’ is one such substring to look out for.
Surely that's something that Apple should fix, rather than everyone else working around it?
Yes, but even if Apple fixes it, you still have to deal with old devices. Better have something that works everywhere rather than "this website is optimized for IE/Chrome".
Re: How to store your app's entire state in the url
#239Hah, I came up with the same thing for https://fivethreeone.app/calculator . The reason I did the compression (using pako as well) was that without it the URL was too long to show a preview on iMessage. I also compress the state manually myself which saved a bunch of bytes too.
I discovered when I hit a similar issue, that just putting a "-" character every 40 or so characters resolved the iMessage parsing issue. There may be a max URL length, but I hit it much sooner without the hyphens.
Re: How to store your app's entire state in the url
#240There is a max length to URLs after which it is all wild west based on the browser implementation.