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

31–40 of 416 posts

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

#31

Post by somehnguy »

tlavoie wrote: post #12

As usual when I see this sort of thing, I have questions around the security needs of the application. Storing all of this information on the client means that the client has to be trusted to not mess with all of this state. If it's important, it needs to be stored and checked server-side.

Validating data from the client should always be done on the server in that context, regardless of if state is being saved client side or not. I think this is just an extension of what you said though.

I can think of many apps that don't need server side data storage or security that would benefit from this type of state saving however. For example, this app that I was using today - https://wheelofnames.com/ . Right now to save I need to create an account, presumably to tie my account to the saved state on the server side. That's pretty heavy/intrusive when all I want to do is keep the names list and preferences populated for my next visit.

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

#32

Post by culi »

rcme wrote: post #21
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.

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

well you don't have to store ALL of your data this way. Also you can always just choose to send it to the backend still with a POST

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

#34

Post by Zamicol »

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.

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

#36

Post by nerdponx »

hardwaregeek wrote: post #23

I love doing this for playgrounds! It's so nice to be able to share a link with the code embedded. Especially if you're giving someone a bug report and they need a minimal reproduction.

I appreciate this feature a lot on sites like https://tio.run and https://mermaid.live/. However the URLs also get very long and I often want to run them through a shortener for e.g. posting to IRC. But there are worse problems to have!

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

#37

Post by ErrantX »

devmunchies wrote: post #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 st…

I am genuinely intrigued as to why that's better?

Especially as in the second part of your comment you restrict shareability/usability significantly from what the author wants to achieve (IE I can't as a free user bash out a diagram and share it, then later do another and share with a different person).

In fact the solution is so elegant when you think on it; free account volume is incredibly scalable, zero storage cost, offer immediate value but also a really simple upsell to pro accounts (save to the DB so you don't have to save the URls).

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

#38

Post by jonny_eh »

mguerville wrote: post #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"

Great YouTube channel about reverse engineering old game password systems: https://www.youtube.com/playlist?list=PLzLzYGEbdY5nEFQsxzFan...

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

#39

Post by colejohnson66 »

mguerville wrote: post #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"

The downside of a lot of those "password" save systems was that you lost your lives, and sometimes more. The password sometimes just wasn't long enough to store enough information. For example, Driver[0] (at least on the Game Boy) is an icon-based one with eight(?) symbols per field and four fields. That's only 12 bits.

[0]: https://en.wikipedia.org/wiki/Driver_(video_game)

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

#40

Post by escot »

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.

This is a great point, but also depends on what browsers you want to support. In my experience some browsers a) will truncate the url when you try to copy it from the browser bar (safari), and b) will not support any url including the hash past a certain cut off (like the SO comment states).
Post reply on HN