Live data from Hacker News

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

scottantipa.com

21–30 of 416 posts

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

#21

A better idea is to use the URI fragment (the string after the # sign). It has the advantage of not having a size limit, and not needing to be sent all to the backend during the request. `window.location.hash` is your friend.

Sometimes you might want the state on the backend, e.g. to generate open-graph metadata tags.

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

#22
post #13

I tried to do that at first with https://textshader.com because the whole site is client-side and I didn't want to bother with a backend. It didn't really work because the state is unbounded in size, so instead I just chuck it on GitHub gists and then point to the gists. It means I don't have to store any data myself and there's zero recurring costs outside of the domain name... but if the site ever got popular I'd p…

I dream of a world where there’s some kind of ipfs like thing for storing state in some sort of distributed commons, all while maintaining user privacy/allowing for state to expire if untouched, and monetized in a balanced way to incentivize hosting without discouraging consumer adoption too much/trending towards gouging.

We’re so close/all the pieces needed seem to exist, but getting something like that off the ground is super difficult.

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

#24
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

Love the app!

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

#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 state (ephemeral, lasts component lifecycle)

2. temp app state (in-memory, lasts the session)

3. durable app state (persistent, whether localstorage or indexeddb or whatever)

4. sharable app state (url)

5. individual user data (private)

6. team user data (shared)

7. global data (public)

and CRUD for all these states should be as easy to step down/up as much as possible with minimal api changes as possible (probably a hard boundary between 4/5 for authz). this makes feature development go a lot faster as you lower the cost of figuring out the right level of abstraction for a feature

0: relatedly, see The 5 Types of React Application State, another post that did well on HN https://twitter.com/swyx/status/1351028248759726088

btw my personal site makes fun use of it -> any 404 page takes the 404'ed slug and offers it as a URL param that fills out the search bar for you to find the link that was broken, see https://www.swyx.io/learn%20in%20public

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

#26
Seems like it could be better to store the state in a database and create a unique, short ID that goes in the URL, especially if your doing server rendering (like SSR react or HTMX, or rails/Django)

> I also didn't want to store anything on the backend (at least for the free tier).

You can make the state unique in the DB by a user cookie ID and then upsert the state which will overwrite older state with the latest state. Then you only have 1 record per free user. Remove record that haven’t been modified in 30 days and you don’t have much overhead. Just off the cuff thinking.

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

#27
Isn't this also how old school games (I've seen it as late as the NES I think) did allow you to save progress, you'd get a short string as your "save" and could just enter it to restart the game in the same state later. I love that it offers essentially unlimited "saves"

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

#28

A better idea is to use the URI fragment (the string after the # sign). It has the advantage of not having a size limit, and not needing to be sent all to the backend during the request. `window.location.hash` is your friend.

I wrote a library based on that very idea. It supports fragment query, just like normal queries.

https://github.com/Cyphrme/URLFormJS

I use it in a lot of places, like: https://convert.zamicol.com/#?inAlph=Text&in=Hello%20world!&...

https://cyphr.me/ed25519_applet/ed.html#?msg=Hello%20World!&...

https://cyphr.me/coze#?verify&input={%22pay%22:{%22root%22:%...

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

#29
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

There is a size limit though that quickly gets exhausted if you are storing text (2000 chars)

You're right, its a limitation. Knotend also supports upload/download of a .knotend file to get around this.

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

#30

A better idea is to use the URI fragment (the string after the # sign). It has the advantage of not having a size limit, and not needing to be sent all to the backend during the request. `window.location.hash` is your friend.

> It has the advantage of not having a size limit

Still though I suppose you could probably gzip it before base64 encoding it for some additional optimization.

Extremely long URLs have other UX issues, e.g. sending them on chat apps and having them eat up multiple scroll pages in one URL, like:

"Check out this event:

http://..... ... ... (500 scroll-screen-lengths of just URL) ... ...

Here's another event on the same day:

http://..... ... ... (500 scroll-screen-lengths of just URL) ... ...

Can you let me know what you think and which one you'd like to go to?"

Post reply on HN