Live data from Hacker News

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

scottantipa.com

381–390 of 416 posts

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

#381

Earlier quoted context omitted.

This is a terrible example though, there is no reason why those shouldn't be normal query parameters.

I don't see why normal query parameters (using ? symbol) would be better than putting the key/value pairs after a # symbol. They both achieve the purposes of allowing custom URLs that bring the user to a specific state of the app.

An often unintended side effect of using the URL hash to contain state is that it breaks potentially linking to an anchor element ID somewhere in the page. Obviously this doesn't matter much if the page doesn't use anchor IDs or you don't intend on users doing that.

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

#382
post #333

Earlier quoted context omitted.

> I'm not into web "programming" Elaborate

I write performance-critical code where it is normal to count bits, not just bytes, and keep track of number of instructions generated by your code. The whole web thing where people shove everything into a browser is just weird to me.

What's weird about passing an application state back and forth in a serialized format? Surely your counting bits example can be extrapolated to make sense of that.

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

#383

App 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 feel like you're ignoring the context of the linked post while also trotting out the most obvious comparison of all times.

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

#384
post #25

This is quickly becoming a standard in apps and it really shouldnt be handrolled since its such a common requirement and easy to get wrong (between serializing/deserializing/unsetting states). In Svelte it is now as easy as using a store: https://github.com/paoloricciuti/sveltekit-search-params in general i've been forming a thesis [0] that there is a webapp hierarchy of state that goes something like: 1. component s…

Could we please stop this "shouldn't be handrolled" or "don't write your own X". It only results in pushing some false idea that you have to be special to do these things, or that innovation is impossible. I can't believe we went from "don't roll your own crypto" to a plain thing like "don't roll your own url state management". What? That is obviously exactly what you should do to get a deeper understanding of the technologies you're working with. I think the only people I hear say this is because they have some agenda in pushing developers to be "tool users" instead of "problem solvers".

It's not that you shouldn't say "there be dragons" or suggest existing solutions, but that's doable without saying you shouldn't do X at all...

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

#386
post #324

Earlier quoted context omitted.

Right, but having them all be the same is what people are joking about :) Although I might check the lisp/clojure vs java code on techempower or another rosetta stone like example.

That, and the usual style of stacking all closing parentheses together at the end of the last line of a sub-expression / statement / whatever. People sometimes do this in Java and it's just as unreadable.

You read it by indentation not by counting parentheses.

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

#388

Worth to note that it actually should use the base62 https://en.wikipedia.org/wiki/Base62 It’s the same as base64 but w/o "+" and "?" symbols.

There is a URL safe version of base64 that uses - and _ instead. Base64 tools can be more readily available.

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

#389
post #2

Hey all, I made this post to show a technique that I'm using in my keyboard-centric flowchart editor [0]. I really love urls, and the power that they hold, and would love to see more apps implement little hacks like this. Also, another shout out to mermaidjs and flowchart.fun for also implementing similar url-based sharing. [0] https://www.knotend.com

If the schema is fixed, using proto buffers will greatly reduce the length required.

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

#390
post #330

Earlier quoted context omitted.

Isn't storing state in urls and then using a url shortener just a key/value store with extra steps?

But with added session id energy too!

True, though I think the differences around shareability matter— a mapping-table entry is immutable, whereas even a non-logged-in session token is probably not.
Post reply on HN