An alternative to having Immutable transitions within the API itself (e.g. declare a Store and it gives you an Immutable on every read, it might be preferred to make Immutable an optional configuration.
This would be achieved by having the store creator pass an Immutable<T> directly as the state type - effectively opting in to Immutable.
The consequences would be the same, but those who don't want to deal with the complexity of the Immutable interface (who are self-disciplined) can choose not to use it as it can add complexity to other parts of the codebase which DON'T understand immutability.
This could be facilitated by a createImmutableStore which enforces the transition maybe?
cefn
commented
9 months ago
An alternative to having and it gives you an Immutable on every read, it might be preferred to make
Immutabletransitions within the API itself (e.g. declare a StoreImmutablean optional configuration.This would be achieved by having the store creator pass an
Immutable<T>directly as the state type - effectively opting in toImmutable.The consequences would be the same, but those who don't want to deal with the complexity of the Immutable interface (who are self-disciplined) can choose not to use it as it can add complexity to other parts of the codebase which DON'T understand immutability.
This could be facilitated by a
createImmutableStorewhich enforces the transition maybe?