The state should be immutable

Current state

Since the addition of modules, the state is no longer immutable: when an action, or a nested action, or an action in a module is called, its result is merged with the current state (or state slice for nested actions/modules).

This prevent users from using memoize functions on the view with simple === checks for equality checks and forces to use deep equality.

For example, the following pen should work with immutable state: https://codepen.io/mytrill/pen/WZmVWQ?editors=0010

I believe for large apps, the benefit of having very cheap memoize functions based on immutable state far outweight the cost of maintaining an immutable state (both in terms of performance and source code size).

Expected behavior

When an action gets executed, the result that it returns should get merged to the state slice/module’s state this action operates on and create a new instance of the state and re-use the part of the state that hasn’t been touched. Here is an example: https://upload.wikimedia.org/wikipedia/commons/thumb/5/56/Purely_functional_tree_after.svg/438px-Purely_functional_tree_after.svg.png

In this case, when the node “f” is modified (“e” gets added to it) the update function recursively goes up the state tree, creating new nodes when modified and re-using un-touched nodes.

Advantages

• Allow debug tools to keep the state history and implement time travel
• Allow very performant memoization of components/views on large app (deep equality on state can be checked with ===)

Drawbacks

• small performance penalty when executing nested action (need to duplicate a whole branch of the state-tree
• extra logic/bundle size

Implementation

PR #426 addresses this issue

[jorgebucaran]

@lukejacksonn BTW, I need more time before merging #424, since I am not sure it interferes with making the state immutable again.

[lukejacksonn]

Immutable guarantees, cheap memoizing, negligible perf hit and somewhat of an existing implementation… for ~100b you say 🤔 sounds like good deal to me 💸