4 ms·

LocalStorage is tied to a device. The kind of settings described in the article should be tied to an account. Component state should only contain volatile data

LocalStorage is tied to a device. The kind of settings described in the article should be tied to an account. Component state should only contain volatile data that is not important to save, the opposite of LocalStorage.

anaclet0 7y ago
Totally agree. I usually have a /userSettings api to store all the user customized UI settings (e.g. sidemenu collapsed or not, theme, etc.)
PNWChris 7y ago
Edit: I misread the parent comment, apologies for that! After re-reading, I still agree with them, but with some nuance. This article describes "somewhat" volatile state, and I think there are interesting use-cases for temporary sticky state that stays between visits (but doesn't need to be stored permanently). I see this being cool for search filter states and stuff. I'll leave my original comment as-is because I still thought that was worth sharing, too. -- I've put a lot of thought into easy, no DB persistence for a project of mine, and I have to agree with your assessment. I ended up persisting to the private fragment identifier (hash) portion of the URL. It makes bookmarking and copy-paste state sharing easier. Most major browsers have a bookmark sync feature these days, so state sync is free (a nice benefit!). While researching persistence options, I came across storage.sync[0]. It's like local storage, but synced across browsers. I've never used it, but the promised functionality would be very cool. I think storage sync is a really good idea. I just wish there was a "web browser state file system" of sorts for users to browse, copy, back-up, etc. In absence of that, I feel no user can be confident that local storage is working, and as a consequence I won't persist anything of consequence there. [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/sync https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
- pault 7y ago
  Chrome has the FileSystem API, but they couldn't get the other vendors on board and it's basically dead now. https://stackoverflow.com/questions/23560090/is-the-fileapi-in-html5-dead https://stackoverflow.com/questions/23560090/is-the-fileapi-...
Waterluvian 7y ago
Yes. When possible. If you're not about to set up a server side of things, this works great. I have a few completely serviceless web apps that utilize localstorage for this kind of thing.
marstall 7y ago
what's the best way to do that - tie the data to an account?
- the_gipsy 7y ago
  Having some kind of "settings" object together with the account sounds reasonable. However someone above made the point that sometimes LS _is_ a good idea, I just wouldn't do it at the component level.
alexrage 7y ago
> Component state should only contain volatile data that is not important to save, the opposite of LocalStorage. Where do you store data that you retrieve from a server for rendering? Storing it in the state is perfectly fine. In this example, data is retrieved from local storage and stored in the state.
- the_gipsy 7y ago
  Fair point, but server state is tied ti my account, LS is not. You can tie LS to the account, but IMO that would be out of scope for an "everything component" approach, like the article.
holler 7y ago
> The kind of settings described in the article should be tied to an account. I disagree, these kind of settings should not be tied to the account as an account may be accessed across multiple devices. Using LS to store device-specific preferences seems like a good solution to me.
- the_gipsy 7y ago
  Ok I see your point, LS might be the right place to save such a state. However, I still disagree on doing it on a component level (with hooks or whatever). If I log out, that LS should be gone in most cases. Either the logout must know too much about specific components (leaky abstraction), or the components will need to handle too many edge cases.
  - foota 7y ago
    Perhaps you could build the LS storage on top of a per-profile local storage? I.e., you have something that on login creates a local storage key value for the active user, and then when someone logs out that is cleared (or it's keyed by user id and only used when that user is logged in). Components adding something need to add it to that key somehow, or could make use of prefixes. (the lack of structured data in local storage hurts a little here) This way the thing managing the profile doesn't need to know what people are storing, and the components can still clear on logout.
    - pault 7y ago
      I consider this a best practice. I always key my localstorage values to the user account and build version so you don't get issues with old localstorage schemas causing bugs when a new build is released.
  - hjnilsson 7y ago
    I would suggest just calling clearAll on localStorage upon logout. To keep it simple.
ficklepickle 7y ago
An appropriate use is as a progressive enhancement. For example, I use a similar approach in an open source trivia game[0] to store the last categories selected. Then, when a new game is started, these categories are pre-selected but easily changed. It's not crucial to the game play, but it is convenient. It can also be used in PWA's when offline. [0] https://justtrivia.fun https://justtrivia.fun

anaclet0 7y ago

Totally agree. I usually have a /userSettings api to store all the user customized UI settings (e.g. sidemenu collapsed or not, theme, etc.)

PNWChris 7y ago

Edit: I misread the parent comment, apologies for that! After re-reading, I still agree with them, but with some nuance. This article describes "somewhat" volatile state, and I think there are interesting use-cases for temporary sticky state that stays between visits (but doesn't need to be stored permanently). I see this being cool for search filter states and stuff. I'll leave my original comment as-is because I still thought that was worth sharing, too. -- I've put a lot of thought into easy, no DB persistence for a project of mine, and I have to agree with your assessment. I ended up persisting to the private fragment identifier (hash) portion of the URL. It makes bookmarking and copy-paste state sharing easier. Most major browsers have a bookmark sync feature these days, so state sync is free (a nice benefit!). While researching persistence options, I came across storage.sync[0]. It's like local storage, but synced across browsers. I've never used it, but the promised functionality would be very cool. I think storage sync is a really good idea. I just wish there was a "web browser state file system" of sorts for users to browse, copy, back-up, etc. In absence of that, I feel no user can be confident that local storage is working, and as a consequence I won't persist anything of consequence there. [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/sync https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

pault 7y ago
Chrome has the FileSystem API, but they couldn't get the other vendors on board and it's basically dead now. https://stackoverflow.com/questions/23560090/is-the-fileapi-in-html5-dead https://stackoverflow.com/questions/23560090/is-the-fileapi-...

Waterluvian 7y ago

Yes. When possible. If you're not about to set up a server side of things, this works great. I have a few completely serviceless web apps that utilize localstorage for this kind of thing.

marstall 7y ago

what's the best way to do that - tie the data to an account?

the_gipsy 7y ago
Having some kind of "settings" object together with the account sounds reasonable. However someone above made the point that sometimes LS _is_ a good idea, I just wouldn't do it at the component level.

alexrage 7y ago

> Component state should only contain volatile data that is not important to save, the opposite of LocalStorage. Where do you store data that you retrieve from a server for rendering? Storing it in the state is perfectly fine. In this example, data is retrieved from local storage and stored in the state.

the_gipsy 7y ago
Fair point, but server state is tied ti my account, LS is not. You can tie LS to the account, but IMO that would be out of scope for an "everything component" approach, like the article.

holler 7y ago

> The kind of settings described in the article should be tied to an account. I disagree, these kind of settings should not be tied to the account as an account may be accessed across multiple devices. Using LS to store device-specific preferences seems like a good solution to me.

the_gipsy 7y ago
Ok I see your point, LS might be the right place to save such a state. However, I still disagree on doing it on a component level (with hooks or whatever). If I log out, that LS should be gone in most cases. Either the logout must know too much about specific components (leaky abstraction), or the components will need to handle too many edge cases.
- foota 7y ago
  Perhaps you could build the LS storage on top of a per-profile local storage? I.e., you have something that on login creates a local storage key value for the active user, and then when someone logs out that is cleared (or it's keyed by user id and only used when that user is logged in). Components adding something need to add it to that key somehow, or could make use of prefixes. (the lack of structured data in local storage hurts a little here) This way the thing managing the profile doesn't need to know what people are storing, and the components can still clear on logout.
  - pault 7y ago
    I consider this a best practice. I always key my localstorage values to the user account and build version so you don't get issues with old localstorage schemas causing bugs when a new build is released.
- hjnilsson 7y ago
  I would suggest just calling clearAll on localStorage upon logout. To keep it simple.

ficklepickle 7y ago

An appropriate use is as a progressive enhancement. For example, I use a similar approach in an open source trivia game[0] to store the last categories selected. Then, when a new game is started, these categories are pre-selected but easily changed. It's not crucial to the game play, but it is convenient. It can also be used in PWA's when offline. [0] https://justtrivia.fun https://justtrivia.fun