SwitchbackTech
Document State Management Strategy
Prevent "impossible" state inside the store
I have noticed that in some places, the store uses a few variables to describe the state of the same thing (a request status). But the possible value combinations for these variables are not implicit, which could lead to impossible states in the long run, which are considerably difficult to debug.
My suggestion to prevent impossible states: map the possible states (maybe create an interface for each?) and add the types to the store. Or, to be more specific: instead of having multiple state variables (isProcessing, isSuccess, value, error) there could be only status ("processing" | "success" | "error") and value (either the success payload or the error message). That way we would get a compilation error every time we tried to assign an impossible state to the store (like isSuccess equal to true and a non-nullish value for error), preventing bugs and leading to a more predictable state.
Retitled this issue to make it a living document to discuss to improve the state management strategy.
We're currently focused on working with the tools/patterns we have, but we will need to make some changes over the medium term to avoid getting crippled by the tech debt.
Feel free to keep adding suggestions to this issue as they come up.
