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/Web...

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

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

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.

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.

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.

I would suggest just calling clearAll on localStorage upon logout. To keep it simple.

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.

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

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.

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

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

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

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.