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.
Component state should only contain volatile data that is not important to save, the opposite of LocalStorage.
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/Web...
https://stackoverflow.com/questions/23560090/is-the-fileapi-...
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.
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.
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.
I have a few completely serviceless web apps that utilize localstorage for this kind of thing.
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.
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.
However someone above made the point that sometimes LS _is_ a good idea, I just wouldn't do it at the component level.