A mutation changes system state. The tempting design is to modify a hash map in place, but that makes invalid states harder to prevent and erases previous versions. A multi-version design instead advances a state reference from one immutable data version to the next, much like Git tracks commits. section 4.1 section 4.0
The crucial distinction is simple: the data is immutable, while the state reference is mutable. This confines statefulness to a small, common commit operation. section 4.1 section 4.0
Handle a mutation in two phases:
- Calculation computes the next data version with immutable functions. It is stateless and specific to the mutation. section 4.0
- Commit moves the system state forward to that version. It is stateful, common to all mutations, and can validate the complete data set before the move. section 4.0 section 4.8
- Structural sharing keeps unchanged parts between versions shared rather than copied, limiting memory and computation costs. section 4.0 section 4.8
Changing one map field
Instead of using a native hash map setter, use an immutable operation such as Lodash FP's set(map, path, value). The operation returns a new version, leaving the received data unchanged; the commit phase then makes the state reference point to it. section 4.8
Table 4.1 The two phases of a mutation (view table figure)
Compare calculation and commit by responsibility, statefulness, and implementation scope. section 4.0
