Replies: 2 comments
-
there are lots of choices out there to make a deep copy of an object, including lodash. Doing a proper deep clone while supporting all edge cases has a certain complexity to it, so I don't think we should move such a feature into core if there are well-tested, widely used alternatives out there. |
Beta Was this translation helpful? Give feedback.
-
@LinusBorg But when make a deep copy of an readonly object, we still can't modify the new Obj cause the new Obj's type still Readonly. We need a unReadonly feature, not deepCopy feature.(I'm so sorry, I seem to have taken the focus of the problem off center)That's what I'm talking about.The deep copy object is only used to describe the final return value different from the original object. |
Beta Was this translation helpful? Give feedback.
-
What problem does this feature solve?
Unreadeonly API unpacks the readonly object. Return value of API is the copy / deepClone object of source object.
when export a store witch readonly wrap up, due to the exported store type is DeepReadonly, any other variable receiving its value also needs to be declared as Readonly type, which will make it impossible to modify other variables receiving its data value, Readonly types are contagious like a plague and cannot be blocked
What does the proposed API look like?
Type:
Example:
Beta Was this translation helpful? Give feedback.
All reactions