simpleDeepFreeze when setting your application state to make sure you can use reference equality when determining which parts of your app to update, and to make sure it's always serializable.
var simpleDeepFreeze = ;var obj = a: b: 1 c: 2 3 ;;objab = 2; // error (when in 'use strict' mode)console; // 1objc0 = 100; // error (when in 'use strict' mode)console; // 2; // error; // error
In production environments (based on
process.env.NODE_ENV) we skip freezing to improve performance.
When encountering an object that is already frozen, we assume it has been frozen recursively already. Make sure that this assumption is true by not using libraries that shallow-freeze objects, and by not shallow-freezing objects yourself. We recommend using the following ESLint rule:
'no-restricted-properties': 'error'object: 'Object'property: 'freeze'message: 'Use simpleDeepFreeze instead.'
Freezing data structures helps with certain performance optimisations, such as being able to use reference equality to check if the data structure has not changed, instead of a deep comparison.
Using only plain objects, arrays, and primitives makes it easy to serialize and deserialize data, e.g. using JSON. This is useful to synchronise data between different computers or processes (e.g. persisting data, synchronising between browser windows, and so on).
- Immutable.js, as mentioned above.
- seamless-immutable tries to make sure you're working with immutable data everywhere throughout your application, by overriding methods like
Array.prototype.map. This is pretty complicated and error-prone. In contrast, we recommend using
simpleDeepFreezeonly at critical touchpoints in your application, such as setting your application state. This gives you largely the same benefit, but without the complexity.
- deep-freeze is very similar but does not enforce simple data structures. People have had a few issues with the library because of this.