RFC: Provide option for strict immutability of selectors's output

[samuelfernandez]

It is great that the store returns an immutable JS object, which helps in finding bugs in case the state was modified outside of the reducer by mistake. Lately, this has become a core part of the framework, including actions, which is nice.

However, we also have selectors. I have faced the problem of mistakenly modifying an object coming from a selector, which caused undesirable side-effects.

It might be nice that the results of createSelector were made immutable at the output to make sure they are not modified, since eventually a selector is an extension of the store's data. This could be a breaking change for some apps, so maybe it could just be an opt-in option in the root settings, or an option at each createSelector

Describe any alternatives/workarounds you're currently using

Be a good programmer and avoid going evil

If accepted, I would be willing to submit a PR for this feature

[x] Yes (Assistance is provided if you need help submitting a pull request)
[ ] No

[david-shortman]

Putting this on my radar to possibly work on

[samuelfernandez]

If you give me some guidance and green light I'm willing to try and submit a PR

[brandonroberts]

Thanks @samuelfernandez and @david-shortman. We will give some guidance. Don't start on any work on this just yet

[samuelfernandez]

Any updates on this @brandonroberts?

[david-shortman]

I'd be happy to look at for v14 or beyond.

[BrianCerasuolo]

Should return values be immutable as a best practice? Specifically talking about derived values that are transformed from store state that is already in the reducer.

[samuelfernandez]

Yes, otherwise two consumers of a selector may have different values, or different from their initial value