Using react-broadcast with localstorage adapter clears localstorage on page reload
ibratoev opened this issue · comments
Describe the bug
react-broadcast + localstorage adapter + adapter.updateFlags does not work properly.
To Reproduce
We use react-broadcast with the localstorage adapter. We have implemented a view where a super admin can change different feature flags. We call adapter.updateFlags to update the flags. Reload the page after the feature flags have changed in localstorage.
** Current behavior**
Localstorage is cleared after the first page reload (at least the config is properly loaded). After a second reload the flags state is completely lost.
Expected behavior
Localstorage is not cleared on page Reload.
Additional context
Related to #1498
Whenever ConfigureFlopFlip is rendered for a first time - the adapter is reconfigured.
Thanks for looking more into the adapter. I think it makes perfect sense for the adapter now to clear if the user can be identified as the same. I wanted to avoid flags of user A restoring flags for user B as a sort of "flash or unloaded flags".
@tdeekens Maybe I don't understand completely the idea of the localstorage adapter.
In my view, a local storage adapter syncs any changes to localstorage and syncs from it on some interval.
Why would you use a localstorage adapter if it cleans up localstorage on page reload. You can just use the memory adapter with the same success.
What is the use case of the localstorage adapter?
The use case is exactly what you described. I was only wondering what would happen if you user A visit a page. Then flags are persisted to local storage. Then you logout and login as user B. Now flags from user A would be restored. This could be unintended. Maybe it's not worth considering this case though. What's your take on this? :)
Ah, I think I understand you now. Your concern is when a new user logs in.
My guess is that it is up to the developer to update the adapter when a new user logs in. My guess would be that the localstorage adapter is used in scenarios where the developers have control over where the feature flags come from and when they are updated.
Yes, either it's a concern we delegate to a consumer of the library or we allow passing in a user key/ID which scopes what is saved and restores it. I think the latter would imply a bit less work for a consumer of the adapter. What do you think?
Yeah, making it a bit easier with user key/id is fine. But it should be opt-in behaviour. If the user does not provide a user key - it should leave it to the library user for how to control the storage.
@tdeekens, whit all this said, what do you think should be the fix to my original issue - localstorage adapter clears localstorage on page reload without any user key/id provided?
Sorry for the late reply and latency. Parental leave means keeping an eye on other things :)
I think, if I understand you correctly, what you propose would solve your issue. If a consumer provides a key which can be something the user stores e.g. in localstorage him/herself or is a user uuid than that's used to scope the localstorage items and flags written. It also means that the same flags will be restored if the same uuid is passed between reloads. If one doesn't provide a uuid then the flags are not scoped and one wouldn't prune localstorage. The second is a bit debatable as it would theoretically be an unintended change for some but I think it's for the better.
What do you think?