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?
An alternative to having and it gives you an Immutable on every read, it might be preferred to make
Immutable
transitions within the API itself (e.g. declare a StoreImmutable
an 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
createImmutableStore
which enforces the transition maybe?