Many users can connect to tzsafe on the same computer, on the same browser. The app state has to be different between this two users.
For instance maybe Alice has different safe than Bob. Even if everything is public it's more user friendly if Alice/Bob are only aware of what they want. Bob may wants to follow the state of specific safe and Alice not, etc...
However, the more the app grows the more the state logic becomes complicated. And the probability of introducing bugs in the state management are greater.
Suggestion
What I suggest is to refactor the state serialization. The goal is to support many states (one state by user) in the localStorage. To be more specific I suggest to save the state under the key app_state:{key} where the key is the public key of the connected user. And to load the state from app_state:{key} when the key is the key of the newly connected user.
Example: Bob is connected with the address tz1cBUPLRLzM77p5iQKTUxfDUp3vwPp9BKfQ then the state of this users is located under the key app_state:{tz1cBUPLRLzM77p5iQKTUxfDUp3vwPp9BKfQ}.
When this refactor is done. The state can be simplified. The simplification consist of removing the multi-user management. Because we can admit that the state contains only information related to the connected user
Context
Many users can connect to tzsafe on the same computer, on the same browser. The app state has to be different between this two users.
For instance maybe Alice has different safe than Bob. Even if everything is public it's more user friendly if Alice/Bob are only aware of what they want. Bob may wants to follow the state of specific safe and Alice not, etc...
The MR https://github.com/marigold-dev/tzsafe-ui/pull/171 solves this issue that was described in https://github.com/marigold-dev/tzsafe-ui/issues/174
However, the more the app grows the more the state logic becomes complicated. And the probability of introducing bugs in the state management are greater.
Suggestion
What I suggest is to refactor the state serialization. The goal is to support many states (one state by user) in the
localStorage. To be more specific I suggest to save the state under the keyapp_state:{key}where the key is the public key of the connected user. And to load the state fromapp_state:{key}when the key is the key of the newly connected user.Example: Bob is connected with the address
tz1cBUPLRLzM77p5iQKTUxfDUp3vwPp9BKfQthen the state of this users is located under the keyapp_state:{tz1cBUPLRLzM77p5iQKTUxfDUp3vwPp9BKfQ}.When this refactor is done. The state can be simplified. The simplification consist of removing the multi-user management. Because we can admit that the state contains only information related to the connected user