deepFreeze function on the Mozilla Developer network Object.freeze documentation page.
The reason you would want to freeze an Object would be to make it immutable, meaning that no assignments or re-assignments could be made to the object.
Object.freeze is a shallow operation however so the freeze wouldn’t apply to properties on nested objects. This feature makes perfect sense, nested objects aren’t apart of their parent object, they are different objects, one just happens to hold a referenced to the other in a nested property (but they both could have nested references to each other as well).
Object.freeze operates on the left hand of the colon. In the following example only the properties on
someObj are frozen, the
window object is not effected. If freeze was a deep freeze, then this code would freeze
window and every object nested in window, (including
The example below is the Ramda solution. Don’t
deepFreeze objects with references to themselves or anything else important without adding in extra precautions, as deepFreezing the global object will likely render an app useless until you refresh the page.
If you haven’t yet used Ramda, visit Ramda. Compare the above solution to the Mozilla solution below.
All the comments in the Mozilla code apply to the Ramda version of the
deepFreeze function as well. Give the Ramda implementation a try in the RunKit below:
I don’t even recommend deep freezing as a solution to in-production immutability. You might use
deepFreeze to make sure that your not mutating state prior to deployment. If you freeze your state and your state is large and has frequent changes then it could see a performance dip.. however, if your using
Object.freeze and getting no TypeErrors then you could just remove it for production.