-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
types: changing UnwrapRef to a simpler implementation #579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
# Conflicts: # packages/reactivity/src/ref.ts # packages/runtime-core/__tests__/apiTemplateRef.spec.ts # packages/runtime-core/src/apiWatch.ts
@yyx990803 is this useful or just close it? |
Can you remove the formatting changes from this PR? |
formatting fixed after merging 1068212 |
packages/reactivity/src/ref.ts
Outdated
| CollectionTypes | ||
| BaseTypes | ||
| Ref | ||
| Element |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems unnecessary since BaseTypes
includes Node
packages/reactivity/src/ref.ts
Outdated
? Tupple<T> extends never ? Array<V> : UnwrapTupple<T> | ||
: T extends object ? UnwrappedObject<T> : T | ||
|
||
export type UnwrapTupple<T> = { [P in keyof T]: T[P] } & { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export type UnwrapTupple<T> = { [P in keyof T]: T[P] } & { | |
export type UnwrapTuple<T> = { [P in keyof T]: T[P] } & { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not fully understanding what case UnwrapTuple
is supposed to handle - can you add a type test case for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think is needed, since we don't unwrap arrays anymore, was to fix the type inferring of
type UnwrapArray<T> = { [P in keyof T]: UnwrapRef<T[P]> }
// the array would be converted
/*
[1, 2, '1']
to
{
'1': 1,
'2': 2,
'3: '1'
}
*/
Co-Authored-By: Evan You <yyx990803@gmail.com>
Oops, looks like I hit the button at the wrong time |
Sorry for the accidental merge, can you open a follow up PR for the type test fix please? |
Sorry about that, should have run the testing before pushing |
This is a type I was really careful not to break anything, I hope I haven't missed anything.
Overall this shouldn't affect much, but it improves when using
Ref
on a generic function.I'm porting my vue composables library to use the new
reactivity
and because of the nature of the library, my functions are quite generic, and ran into some issues with the typescript type checking.It works using @vue/vue-composition, but when I use
@vue/reactivity
it has some errors, and not really readable errors since the typescript type is quite weird to because of the recursive implementation.Full method working with plugin
Reproduction code
I don't believe with a recursive approach we will be able to fix this without a cast, because I've raised microsoft/TypeScript#33942 some time ago, but seems to be a design limitation so I don't expect it to change any time soon.
EDIT: Having issues with Portal and inferring the children on
h
EDIT2: Still having issues with the portal seems to not be inferred, the issue being with
ref<VNodeChildren<TestNode, TestElement>>
be able to be converted toRawChildren
therefor not be able to match with the overloadEDIT3: It can be fixed by casting to the correct type:
EDIT4: merged with master and made a few changes to be able to pass the testing.
Has been some time since I opened this PR, but my problem was getting error:
The value of this PR is the error messages, instead of having the unreadable message from recursion, you have a message like:
Probably in the next few days I will do a bit more testing