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

301–310 of 416 posts

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

#301

Post by didericis »

winrid wrote: post #299
anon223345 wrote: post #288

I saw a $12 million app have to be essentially rewritten (at a bank) The “genius dev lead who went to Princeton” kept pushing that they went to Princeton so people stopped arguing against it Tried to do this securely and got pwned in the very first demo

I mean, they got pwned because they didn't validate the state against the current user's session. Not because storing state in the URL is insecure.

If you’re validating client url state against server session state that kind of defeats the purpose of trying to put all the state in the url.

You’re technically correct/sounds like you agree it’s still a bad idea, even if there’s a way to duplicate certain state for validation and make it work. Staying shackled to the earth via stupid rules of thumb like minimizing client state in banking apps does keep you from flying straight into the sun, though, which is nice.

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

#303

Post by frosted-flakes »

jcuenod wrote: post #154

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…

You can have multiple values under the same search parameter. For example, ?a=b&a=c&a=d, which would be the array [b, c, d]. Including the index key seems redundant.

The native URLSearchParams browser interface even supports this with the getAll method.

https://developer.mozilla.org/en-US/docs/Web/API/URLSearchPa...

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

#304

Post by noduerme »

I'm sorta debating the merits of various methods like this because there's something I want to "Show HN" which involves browser-based analysis of CSV files... but the way I built it for myself, I just run it on a Node server that parses the file once and stores it as json and serves it when you reopen a project. So now I want to bundle the CSV/json with then project file. But putting it all in a base64 url seems a little crazy when saving/retrieving gzip files from the local filesystem is just as good an option. I think this is interesting as something to consider for shared projects, but probably not ideal if the main goal is to have everything run locally anyway.

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

#305

Post by Ndymium »

saghm wrote: post #265
Ndymium wrote: post #172

Earlier quoted context omitted.

Great minds think alike? I just posted about my URL-using pastebin: https://news.ycombinator.com/item?id=34315577

Oh wow! If you mean November 2022, pretty close to when I was doing mine! If you mean 2021, you definitely had the idea way before me

Nov 2022 it was. Seemed like everyone was having covid, and so was I. The idea came up in a Discord discussion, so I decided to go for it. Later I added the syntax highlighting and file naming. I also added a little extensible header system so that I could add more features in the future without breaking old URLs. Now I'm thinking maybe I should allow extra long URLs (>2048) if the user requests so, they seem to be supported in Chrome/Firefox/Safari...

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

#306

Post by hunter2_ »

owl57 wrote: post #284
TheBrokenRail wrote: post #224

Earlier quoted context omitted.

> by default the reader can't tell what's it about without clicking. Most chat apps like Discord will automatically include an embed generated from a URL's metadata when present in a message.

At least in Telegram, this works for at most one link per message, and quickly fills the screen if you send multiple such messages. And I believe that there is no standard API to get previews of non-public websites in a work chat, you need to develop site-specific bots or something like that?

> previews of non-public websites

It would be interesting if browsers / OSes / apps offered a way to use the browser's cookie jar / basic auth headers / whatever sessioning scheme in whatever apps the user decides should display authenticated previews. Ask the user to allow the release of browser data scoped to the domains that the app suggests. Similar to how some Android apps can put up a prompt to release a Chrome-saved password to an app (which I really wish more apps would include).

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

#309

Post by redbar0n »

> Since I update it on every graph edit, I get something major for free -- undo/redo. The browser's history stack becomes my undo/redo functionality.

A pet peeve of mine is that webapps shouldn’t hijack the browsers default functionality, here being back/forward that should refer to pages, not mutations of the same page.

Ideally, one would have a separate undo/redo button on the page for page or url mutations (which should always be in sync). But mutating the URL shouldn’t be done by pushing to the browser history stack, or if pushing one ought to remember to pop the current entry first so the result is a single mutated page on the history stack.

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

#310

Post by [deleted] »

redbar0n wrote: post #309

> Since I update it on every graph edit, I get something major for free -- undo/redo. The browser's history stack becomes my undo/redo functionality. A pet peeve of mine is that webapps shouldn’t hijack the browsers default functionality, here being back/forward that should refer to pages, not mutations of the same page. Ideally, one would have a separate undo/redo button on the page for page or url mutations (which…

[deleted]
Post reply on HN