Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

scottantipa.com

Post reply on HN
Print view View original

91–100 of 416 posts

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

#91

Post by skrebbel »

mhink wrote: post #71
swyx wrote: 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…

Note on 2: I haven't seen this get a lot of use (or maybe I just haven't noticed it), but the Storage API also provides a `sessionStorage` object [1] with some interesting properties. Not only are values persisted across same-tab refreshes, but if you duplicate the tab, the session values are copied over as well (but they don't remain linked like `localStorage`). An interesting use case for this, IMO, is for tracking…

Unfortunately sessionStorage is not copied over when you ctrl+click a link, and that’s arguably the most common way to “duplicate” a tab. Something about security iirc but i dont grok it.

Still an underappreciated browser feature though, esp for class server-side rendered apps.

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

#92

Post by swyx »

mhink wrote: post #71
swyx wrote: 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…

Note on 2: I haven't seen this get a lot of use (or maybe I just haven't noticed it), but the Storage API also provides a `sessionStorage` object [1] with some interesting properties. Not only are values persisted across same-tab refreshes, but if you duplicate the tab, the session values are copied over as well (but they don't remain linked like `localStorage`). An interesting use case for this, IMO, is for tracking…

i was thinking 2 is more like Redux, btw :)

ive never honestly used sessionStorage as it's not intuitive to me (if i want it clientside i should probably track it serverside, and at that point server is my source of truth)

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

#93

Post by vbezhenar »

lelandfe wrote: post #75
Zamicol wrote: post #34

We wrote a library for storing application state in the URL. Its novel feature is using fragment query, which prevents the information from being sent to the server. https://github.com/Cyphrme/URLFormJS I would love to see it get more use. Here's a small demo: https://cyphrme.github.io/URLFormJS/#?first_name=Bob&last_na... See my other comment on this page for some other examples of its use.

Does this necessarily prevent the ability to provide in-page anchors?

Since you're using JavaScript, you can implement anchors in the way you want.

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

#94

Post by eatonphil »

vbezhenar wrote: post #89
eatonphil wrote: post #84

While this is great for being able to send anyone a URL to a stateful page without needing a backend database, keep in mind browsers have URL length limits and they vary by browser. Compressing as mentioned in the article can help but still you want to know when you're going to go over and figure out a plan for dealing with that.

Chrome limits URLs to a maximum length of 2MB It's more likely that messaging app will have stricter limit than Chrome (and other browsers at this point do not matter). Though I'd suggest to use some kind of server storage if you need to transfer more than few kilobytes of data.

Great point too. At least you can count on being able to send over email.

But yeah, the length will get long and even if the browser can handle it do you really want to be passing around that much text at once?

I'm also curious what various OS clipboard size limits are.

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

#95

Post by swyx »

enos_feedler wrote: post #68
swyx wrote: 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…

So you think of a new feature "X". That feature has a bunch of state it needs to manage. Each piece of state has _requirements_ over where it fits within this hierarchy based on how this state relates to the feature being developed. I don't understand where the cost lowering is? I know instantly where the state should live when I design the feature.

requirements evolve over time. and they tend to go up in terms of persistence/auth/sharability needs. it would be nice to make that easy; and conversely when they arent needed anymore it'd be nice to take the state persistence level down with just a few character changes rather than switching state systems entirely

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

#96

Post by opportune »

redleader55 wrote: post #7

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.

Be careful with this. This is only supposed to be used on the client side. Many HTTP server implementations (and infrastructure you run on) will not let you use the URI fragment even if it does hit the wire, or things like caching will break - you almost certainly want use query parameters for anything backend related

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

#99

Post by austinpena »

WaffleIronMaker wrote: post #77
swyx wrote: 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…

Does anyone know of solutions for this in React?

Tanstack is working on a router that purports to solve a lot of this.

https://tanstack.com/router/v1

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

#100

Post by brundolf »

Something to be careful about here is that browsers/proxies/etc have arbitrary length limits on URLs, and they can vary by quite a lot

We did this once with a web-based REPL, where you could click a button to copy a link to something you'd previously eval'd and then send that to someone else and their buffer would be preloaded with it. It was super nifty, until someone tried it with a buffer that was a few hundred lines long and at least one browser just said "nope". It sounds like OP is doing some smart stuff to minimize URL length, which should help, but there's still a limit somewhere

Post reply on HN