/ core Public
defineComponent() with generics support
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
The type of
defineComponent()when passing in a function has changed. This overload signature is rarely used in practice and the breakage will be minimal, so repurposing it to something more useful should be worth it.
Previously the return type was
DefineComponent, now it is a function type that inherits the generics of the function passed in. The function passed in as the first argument now also requires a return type of a render function, as the signature is no longer meant to be used for other use cases.
Another side effect is that a very specific case of mixins usage breaks:
Note the breakage only happens when calling
defineComponent()inline in the
mixinsoption on a separately declared plain object. This should be extremely unlikely in userland code because if one wants typed mixins, one will certainly define it like this to get type inference for the mixin itself:
This continues to work, so I believe this issue is negligible in practice. It would be nice to fix, but I couldn't figure it out.
This signature is expected to only be used with Composition API. Misc options can be passed via the second argument:
The final component still need runtime props declared. This can be done automatically via a babel plugin, or manually like so:
The type definition ensures that the manual type and the runtime options must match.
Type inference based on runtime
emitsoption is supported, including the matching
onXXXprop on the resulting props interface.