3 ms·

I always use a wrapper around local/session storage[1] to avoid this problem. Then you have your app sync settings with storage, never read from it except durin

I always use a wrapper around local/session storage[1] to avoid this problem. Then you have your app sync settings with storage, never read from it except during startup. It becomes impossible to implement basic UI features like remembering open panes, etc when storage is disabled though. With the current policies around cookies - no cross-domain reads, Safari's ITP - there is no real need to turn them off for privacy reasons, for the average user at least. [1] https://www.npmjs.com/package/localstory https://www.npmjs.com/package/localstory

the_gipsy 4y ago
Basic UI features shouldn't need storage. In-memory or in the URL is enough. If you put it in storage then it is actually a (cookie) session, with some sort of configuration - that's not "basic UI".
- zerocrates 4y ago
  If you define "basic" as not including "this remembers how you had it set last time" then, sure. "In the URL" works for that, sort of, though not if you want it to still work for users that are just re-finding you through Google or typing in your address.
  - the_gipsy 4y ago
    > "this remembers how you had it set last time" That is a session.
    - ricardobeat 4y ago
      And? All desktop and mobile apps are able to persist data. The purpose of disabling cookies was privacy protection, not a 'storing local data is a crime' stance.
- temporallobe 4y ago
  Sure, in-memory works until the page is refreshed. Storing data in the URL is an option, but also messy and cumbersome to manage especially with bookmarks. localStorage / sessionStorage is clean and dead simple, and it actually allows an app to be truly stateful, so it’s quite unfortunate that the trend is to avoid the “evils” of storing any kind of data on the client. What, should we go back to the days of session IDs and server-side storage for even the most trivial data?
  - the_gipsy 4y ago
    This is nothing new: on a webapp, you may not have a session. That's all.

the_gipsy 4y ago

Basic UI features shouldn't need storage. In-memory or in the URL is enough. If you put it in storage then it is actually a (cookie) session, with some sort of configuration - that's not "basic UI".

zerocrates 4y ago
If you define "basic" as not including "this remembers how you had it set last time" then, sure. "In the URL" works for that, sort of, though not if you want it to still work for users that are just re-finding you through Google or typing in your address.
- the_gipsy 4y ago
  > "this remembers how you had it set last time" That is a session.
  - ricardobeat 4y ago
    And? All desktop and mobile apps are able to persist data. The purpose of disabling cookies was privacy protection, not a 'storing local data is a crime' stance.
temporallobe 4y ago
Sure, in-memory works until the page is refreshed. Storing data in the URL is an option, but also messy and cumbersome to manage especially with bookmarks. localStorage / sessionStorage is clean and dead simple, and it actually allows an app to be truly stateful, so it’s quite unfortunate that the trend is to avoid the “evils” of storing any kind of data on the client. What, should we go back to the days of session IDs and server-side storage for even the most trivial data?
- the_gipsy 4y ago
  This is nothing new: on a webapp, you may not have a session. That's all.