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

151–160 of 416 posts

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

#151

Post by s4i »

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…

Yup. Session storage is particularly useful for remembering the initial URL of the user when they leave your app for SSO.

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

#152

Post by tlavoie »

deckard1 wrote: post #135
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.

yep. A coworker introduced a CSRF doing this. I had to point out that you can't just take raw input from a URL and throw it back on the page. Even after I pointed it out and gave a proof-of-concept they still didn't get it.

Right, that's usually when I go into story-telling mode, to paint a picture of exactly the sorts of things I'd be doing with the problem as an attacker. Technical vulnerability descriptions provide useful information, but people often need an idea of what it really means, to them.

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

#153

Post by __MatrixMan__ »

tlarkworthy wrote: post #3
escot wrote: 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)

Store the content in ipfs and just put the hash in the URL?

I haven't used https://github.com/ipfs/js-ipfs in this capacity but I'm under the impression that that's moving bits around like that is more or less its purpose.

Although I suppose this puts a burden on the URL-creator to pin the content until the URL-clicker doesn't need it anymore, which is not how URLs are supposed to work.

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

#154

Post by jcuenod »

This is a useful idea when you've got complex nested state. The problem is changing any particular part of the state is non-trivial. I ended up making `friendly-serializer`[0] to "make objects more accessible in urls."

The idea is that instead of a base64 string, you get something that is much easier to edit in the url bar:

> name=John%20Doe&age=42&address.street=123%20Main%20Street&address.city=Anytown&address.state=CA&address.phoneNumbers.0=123-456-7890&address.phoneNumbers.1=234-567-8901

There's a similar npm project to [0] that I discovered after I'd published this, but I don't recall the name. PRs welcome.

[0] https://www.npmjs.com/package/friendly-serializer

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

#155

Post by hunter2_ »

PUSH_AX wrote: post #137
anshumankmr wrote: post #105

Earlier quoted context omitted.

> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6... Dear god... this link was real. I thought it was like a joke or something

Genuinely curious to hear why you are so shocked. Long, ugly, user unfriendly urls are really prevalent. Arguments can be made even query params are pretty ugly.. Are urls expected to be a good UX these days? What's the big deal?

I don't think people care so much about a messy address bar as a messy chat/email message after pasting a URL. Shorteners and vanity URLs exist, but that's more friction than just copying from the address bar as-is.

This can be overcome with html, markdown, and other rich text formats that let you specify the visible link text (missing from many chat apps*), but that's also friction to compose compared to automatically linking from just a URL.

*Slack's implementation is awesome: type the link text, highlight it, and paste a URL.

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

#156

Post by nanidin »

slivanes wrote: post #126
orasis wrote: post #122

Earlier quoted context omitted.

Another reason to not base64 encode is that many URLs with base64 strings will break in iMessage do to strings randomly matching various keywords that iMessage looks for. I think ‘usd’ is one such substring to look out for.

base64 does not have the problem here, iMessage has. Frustrating.

Curious if English is your mother tongue, and if so, which locale?

As a native speaker of en-US, I would write this as "base64 does not have the problem here, iMessage does."

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

#157

Post by munk-a »

PUSH_AX wrote: post #137
anshumankmr wrote: post #105

Earlier quoted context omitted.

> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6... Dear god... this link was real. I thought it was like a joke or something

Genuinely curious to hear why you are so shocked. Long, ugly, user unfriendly urls are really prevalent. Arguments can be made even query params are pretty ugly.. Are urls expected to be a good UX these days? What's the big deal?

Just because a thing is prevalent doesn't mean it's good. I have a hard time believing all those parameters are completely necessary for the amount of data being displayed. Often times it feels like people just base64encode(page.state) and call it a day.

I think it's advantageous to keep the complexity and specificity of information in URLs to a minimum outside of what's needed to retrieve the data set as it can make backwards compatibility easier - it is valuable (for long lasting tools) to have URLs that users can favorite and share for their common searches.

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

#158

Post by madeofpalk »

opportune wrote: post #96
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

URI fragments being client side are entirely their point. Clients should never send them to the server.

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

#159

Post by jonathanoliver »

oaiey wrote: post #97

Just do not. That or alternatively a hidden field is how asp.net WebForms did it state management 20 years ago. Worst possible idea ever. Good for small scale unimportant external state management but not for your everyday web app.

When I saw this idea all I could think of was the ASP.NET "postback" form data and URL data! I'm glad to not have to deal with that anymore.

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

#160

Post by Zamicol »

ecshafer wrote: post #45

What is old is new again. Back before websites were "Apps", you could often do exactly this (Including Authentication!) right from the url.

Before cookies, I remember in middle school (ebay?) using the URLs for sessions.

If they forgot to include the session token on any link on the page, you'd be logged out and have to authenticate again, or you could navigate backwards back to a sessioned address in your history. Once I figured that out, I copy and pasted my session id so if they omitted the session on a link I wouldn't have to log in again.

Post reply on HN