Live data from Hacker News

How to store your app's entire state in the url

scottantipa.com

291–300 of 416 posts

Re: How to store your app's entire state in the url

#291
post #114

Earlier quoted context omitted.

[flagged]

A horse walks into a bar. Several of the patrons quickly get up and leave, realizing the potential danger in the situation.

A priest, a rabbi and a minister walk into a bar.

The bartender say, “What is this, a joke or something?”

Re: How to store your app's entire state in the url

#292
Here's the non-psuedo code equivalent that can leverage the CompressionStream API rather than using a browserified-gzip-library (eg pako): https://github.com/GoogleChrome/lighthouse/blob/437eb4d757c5...

We use it in Lighthouse for the exact same purpose, a URL #hash full of state. We found that modern browsers support 10mb of data in the hash. https://github.com/GoogleChrome/lighthouse/pull/12509#discus...

Re: How to store your app's entire state in the url

#293
post #134

Earlier quoted context omitted.

OT, we used to joke about LISP source code contains mostly brackets. Nowadays we literally store, transform and pass around willy nillily

we used to joke about LISP source code contains mostly brackets. There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses. So, something like this was perfectly valid: a(1+r(em(2)))))))))))))))))))

That's genious IMO. Making sure the amount of opening and closing parantheses is equal is annoying and unnecesary.

It screams "trust me all good with the closing parantheses".

Re: How to store your app's entire state in the url

#294

Web servers and http enabled services can limit the length of headers and url. While this can be done it runs the risk of having surprises when unknown limits are encountered. Most of these limits are buried deep in docs, not easily visible.

Not really because nothing after the # is sent to the web server.

Re: How to store your app's entire state in the url

#295
About 6 years ago I had to do this on a project. We had charts with a lot of options and we wanted them to be bookmarkable and shared between colleagues. We started with base64, soon moved to a custom encoding with version support https://github.com/ananthakumaran/u

Re: How to store your app's entire state in the url

#297

Earlier quoted context omitted.

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.

Presumably.

Re: How to store your app's entire state in the url

#298
Another way to generate potentially shorter base64 strings is to use something like Python's `struct` to store packed binary data, and then base64 encode that. Better yet, if that data payload can be generated server-side, you can also sign that data payload, which allows you to statelessly verify the data payload itself.

(cf. https://docs.python.org/3/library/struct.html)

Re: How to store your app's entire state in the url

#299

I saw a $12 million app have to be essentially rewritten (at a bank) The “genius dev lead who went to Princeton” kept pushing that they went to Princeton so people stopped arguing against it Tried to do this securely and got pwned in the very first demo

I mean, they got pwned because they didn't validate the state against the current user's session. Not because storing state in the URL is insecure.

Re: How to store your app's entire state in the url

#300

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN