Structure of stores regarding state and actions

Status

Accepted.

It has to be decided how (plugin) stores are structured regarding the separation of state and actions. Several styles were considered.

A: State is only changed through actions, every state value is readonly from the outside.
(+) All effects of a change are collected in the action.
(-) Additional actions are required every time, which causes unnecessary complexity.
(-) readonly has to be implemented every time, both technically and in the documentation.
(-) Changing state through an action is less intuitive.
B: The above only applies if changing the state has an effect that is encoded within the store. Otherwise the state value is mutable.
(-) The mutability of a value has to be changed whenever new side effects arise.
C: State is mutable in principle, as far as changing it is meaningful at all. Derived values are preferably determined via computed, alternatively via watch.
(+) State is always mutable and therefore the easiest to use.
(+) Watchers are already used for inter-plugin communication anyway.
(-) Effects are harder to grasp, as they are not collected centrally in an action.
D: We do not make any rules; everyone writes according to personal preference.
(+) Personal freedom is preserved.
(-) The design of the plugins becomes rather inconsistent.

State is mutable, derived values are expressed as computed. We try to avoid watchers if possible.

(+) Stores are consistent across plugins.
(+) Side effects are collected in an action instead of being spread over the store.
(-) Watchers, which are harder to follow than actions, remain necessary for rare cases.
(-) Consumers need to look up a matching action to change state.