3 ms·
> 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 accoun
by 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 agoOk 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 agoPerhaps 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 agoI 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 agoI would suggest just calling clearAll on localStorage upon logout. To keep it simple.