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

Post by thunderbong » Tue, Jan 10, 2023, 6:23 AM UTC

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…

Post by withinboredom » Tue, Jan 10, 2023, 6:45 AM UTC

hunter2_ wrote: post #306

owl57 wrote: post #284

Earlier quoted context omitted.

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…

Post by enos_feedler » Tue, Jan 10, 2023, 6:53 AM UTC

swyx wrote: post #95

enos_feedler wrote: post #68

Earlier quoted context omitted.

So you think of a new feature "X". That feature has a bunch of state it needs to manage. Each piece of state has _requirements_ over where it fits within this hierarchy based on how this state relates to the feature being developed. I don't understand where the cost lowering is? I know instantly where the state should live when I design the feature.

requirements evolve over time. and they tend to go up in terms of persistence/auth/sharability needs. it would be nice to make that easy; and conversely when they arent needed anymore it'd be nice to take the state persistence level down with just a few character changes rather than switching state systems entirely

Post by lIl-IIIl » Tue, Jan 10, 2023, 7:24 AM UTC

reaperducer wrote: post #279

a_c wrote: post #134

Earlier quoted context omitted.

OT, we used to joke about LISP source code contains mostly brackets. Nowadays we literally store, transform and pass around willy nillily

we used to joke about LISP source code contains mostly brackets. There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses. So, something like this was perfectly valid: a(1+r(em(2)))))))))))))))))))

Post by dzhiurgis » Tue, Jan 10, 2023, 7:28 AM UTC

hot_gril wrote: post #112

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…

> The disadvantages are that your representation of internal state becomes part of the interface This is the biggest reason to avoid this. URLs aren't meant to be used this way. I'd only do it if I wanted a quick and dirty solution.