unReadonly API proposal

[ealldy]

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:

function unReadonly<T>(ref: T | DeepReadonly<T> | Readonly<T>): T

Example:

function useFooCopy(Foo: number | Readonly<number>) {
  const FooCopy: number = unReadonly(Foo)
  return FooCopy
}

[LinusBorg]

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.

[ealldy]

@LinusBorg
I agree that.

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.
This means that a read-write object cannot be created from a read-only object.

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.