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

281–290 of 416 posts

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

#281

Post by __derek__ »

divbzero wrote: post #86

App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…

In a similar vein, I've long been a fan of Kayak's URL structure.[1]

[1]: https://www.kayak.com/flights/SEA-IND/2023-01-10/2023-01-14?...

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

#283

Post by nonethewiser »

IYasha wrote: post #54

I'm not into web "programming", but do people really have to abndon binary data storage these days? I think compressing more informaiton produces still more information. While JSON is by no means as heavy as, for example, XML, it's far heavier than just array of int graph[x][y];

> I'm not into web "programming"

Elaborate

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

#284

Post by owl57 »

TheBrokenRail wrote: post #224
owl57 wrote: post #192

Earlier quoted context omitted.

It's not even only about messiness. " https://news.ycombinator.com/item?id=34315441 " isn't some horrible long base64, but it's not a good UX either: when you paste it in a messenger, or in your notes, by default the reader can't tell what's it about without clicking. > *Slack's implementation is awesome: type the link text, highlight it, and paste a URL. Yes! Matches my vision of hypertext perfectly: I usually type…

> 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?

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

#285

Post by thunky »

galaxyLogic wrote: post #276
divbzero wrote: post #86

App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…

Right no need to put it all in the URL, it could be just a random key pointing to local storage for instance, if not some cloud database.

If it points to local storage then it's not shareable.

If it points to a cloud database then you need a cloud database to do what a url could do.

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

#286

Post by p1necone »

mikepurvis wrote: post #140
dyno12345 wrote: post #119

Earlier quoted context omitted.

you could come up with a better compression scheme given that the dict keys and many of the values are probably common across everyone even if they don't repeat multiple times for a given user. a lot of flexibility would be lost though, and you would need to always update the scheme in a backwards-compatible way.

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.

Isn't storing state in urls and then using a url shortener just a key/value store with extra steps?

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

#287

Post by ben0x539 »

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…

The point of a URL is that I can copy+paste it into IRC so my friends can look at the thing I want to share with them.

If the URL has a bunch of goop in it, people are going to make fun of me for it, especially if it's super long and doesn't fit in a single line. Or if there's stuff in there that's specific to me and not the thing I want to show them.

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

#290

Post by mLuby »

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.

Please don't. The web lives and dies by links, the more specific the better, so #to-an-id or #:~:text=to-search are so much more useful than bad state management that probably only works for that one logged-in user anyway. Put that state in the part of the URL you unambiguously control (query params).

https://web.dev/text-fragments/#textstart

Post reply on HN