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

361–370 of 416 posts

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

#361

Post by depressedpanda »

PUSH_AX wrote: post #171
munk-a wrote: post #157

Earlier quoted context omitted.

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…

> Just because a thing is prevalent doesn't mean it's good. I agree with this sentiment. I'm not sure I've ever seen a url referred to as "good", I was just a bit confused as to why someone would baulk at a URL. In my opinion everything after the host portion of the url is to serve the apps needs, so it knows where to go or what to do, it's not really an interface for the user as obviously there are better ways to pr…

Where I work, we consider URLs part of the UI. Users should be able to share links with each other without pasting a wall of text. We also try to make all URLs human parsable so that they know what they are sharing.

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

#362

Post by jsvaughan »

wtetzner wrote: post #275
mikepurvis wrote: post #140

Earlier quoted context omitted.

Once you've already given up on human-readability, it probably doesn't much matter how long/gross the result is. Rather than spending effort and adding complexity, just provide a built in URL shortener.

Well, there are limits to the lengths of URLs in much of the internet’s infrastructure, so better compression could still be useful.

This is the critical point to make. Paste a few long texts into the boxes and the url goes into the hundreds of thousands of characters long, whereas this says that anything more than about 2000 chars puts you into uncertain territory:

https://stackoverflow.com/questions/417142/what-is-the-maxim...

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

#363

Post by depressedpanda »

hk__2 wrote: post #238
secondcoming wrote: post #174

Earlier quoted context omitted.

Surely that's something that Apple should fix, rather than everyone else working around it?

Yes, but even if Apple fixes it, you still have to deal with old devices. Better have something that works everywhere rather than "this website is optimized for IE/Chrome".

This isn't at all comparable. It's purely an Apple problem.

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

#364

Post by Ndymium »

jansan wrote: post #350
Ndymium wrote: post #163

Last November I had covid and during that time I wrote a little pastebin that runs in the browser, compresses the paste data with Brotli, and puts it in the URL. It has line numbers, file naming, and syntax highlighting so it's feature complete for my own use. Here's a demo, but beware, the URLs are loooong: https://nicd.gitlab.io/t/#NhfW?Qm3F?6-&22c&CQZXuP+Aej5OXzXk7... I find it interesting to sometimes play around…

Is the Brotli compression done in the browser? If so, can you give some insight how this is done?

Yep, it is! You can find the sources on GitLab[0]. The compression is done using brotli-wasm[1].

The entry point to the compression is the syncCompress[2] function, which converts the data to UTF-8, adds the needed header bytes, and then compresses using brotli-wasm. Decompression is done in a streaming way in streamDecompress[3]. This is to avoid zip bomb attacks, where even a short URL could decompress to gigabytes of data, locking the browser. Thankfully brotli-wasm had streaming decompression builtin, I just had to write the wrapper code to update the text content and the status bar in the UI.

You can find the brotli-wasm code I'm using in the vendor folder[4], there is a JS wrapper and then the WASM code (both are straight from brotli-wasm).

[0] https://gitlab.com/Nicd/t

[1] https://github.com/httptoolkit/brotli-wasm

[2] https://gitlab.com/Nicd/t/-/blob/05e587b0183ff80b1c6e050b5d3...

[3] https://gitlab.com/Nicd/t/-/blob/05e587b0183ff80b1c6e050b5d3...

[4] https://gitlab.com/Nicd/t/-/tree/05e587b0183ff80b1c6e050b5d3...

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

#365

Post by arnorhs »

This is an interesting approach. Should help mitigate the URL max length for larger states.

However as some people have pointed out it comes with a few caveats

- The URL is unreadable for humans

- You possibly end up storing things in the URL you did not intend

- For smaller data sets the URL actually becomes larger than the URL params equivalent

- You end up having to deal with version issues, possibly even URL string migrations as the code evolves

I'm sure there still are use cases where this makes sense, but for most applications this ends up being overly complex

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

#367

Post by _7bxa »

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…

This makes sense but also seems very annoying to do? E.g let's say you are storing state in the URL, and now the user wants to save it to their profile. You need to upgrade the state from "encoded into the URL" to "stored in my database", which seems annoying.

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

#368

Post by Brometheus »

typingerror wrote: post #55
AndrewStephens wrote: post #16

This is pretty common and has a bunch of advantages, like the fact you can link to and bookmark a particular state. Also, if you are careful you get undo and redo for free with the browser's back button doing all the work for you. The disadvantages are that your representation of internal state becomes part of the interface - if you ever change your app you need to deal with versioning the state so your new version c…

> If your app has a server component that acts on this state, be super careful about acting on it and treat it as you would any other input under user control. I would recommend signing it if it's generated by the server component, and checking the signature when the server component is provided this signed state. For example to do this in Node is quite straightforward. Key generation: const crypto = require('crypto'…

I did this for passing parameter to a twitter card generator php script :joy:

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

#370

Post by yurishimo »

surume wrote: post #366

Just thinking - are there any security implications to this? Could sensitive data accidentally get added to the URL and then get intercepted?

Sure, but then I think most people would argue that you shouldn't store any of that state in the URL. It definitely is not a panacea.
Post reply on HN