3 ms·
There are other reasons for cloning objects apart from immutable updates. Might also be you just want to pass around an object reference and make sure it is not
by moritzwarhier 3y ago
There are other reasons for cloning objects apart from immutable updates. Might also be you just want to pass around an object reference and make sure it is not mutated later, so you use a clone.
And structuredClone was standardized to serialize objects passed between contexts.
So I don't see what's wrong with teaching people about this as the native way to clone serializable objects.
Record/Tuples are different types and I don't think that "what you really want" is a future proposal when you want a built-in now.
- deleted 3y ago[deleted]
- namuol 3y agoYou’re mostly right, I should have said “what you _probably_ want” instead. Misuse of deepClone & co is just a very common antipattern.
- moritzwarhier 3y agoYeah it is really easy to fall into a misuse of expensive object memoization with deep equality checks if you try to "do it right" in React for example, and work without an external state management library. Or when working with libraries that demand this. In that spirit, I find MobX pleasant to work with as an alternative. Although it remains needed to grok reference equality checks in reactivity, there's no way around that I guess. Fundamentally, when passing messages with structured payloads I'd consider it good style for the payload to be serializable and free from references and mutable state.