Vue-next: Type mismatch for "ref" property of "VNodeProps" interface in generated code

[jbruni]

Version

3.0.0-alpha.8

Reproduction link

https://vue-next-template-explorer.netlify.com/#%7B%22src%22%3A%22%3Cportal%20target%3D%5C%22body%5C%22%3E%5Cn%20%20%3Cdiv%20ref%3D%5C%22modal%5C%22%3E%3C%2Fdiv%3E%5Cn%3C%2Fportal%3E%22%2C%22options%22%3A%7B%22mode%22%3A%22module%22%2C%22prefixIdentifiers%22%3Afalse%2C%22optimizeBindings%22%3Afalse%2C%22hoistStatic%22%3Afalse%2C%22cacheHandlers%22%3Afalse%2C%22scopeId%22%3Anull%7D%7D

Steps to reproduce

Just visit the provided link to Vue 3 Template Explorer, and see the generated render function code.

This is the template:

<portal target="body">
  <div ref="modal"></div>
</portal>

And the generated code contains this snippet:

_createVNode("div", {
  ref: [_ctx, "modal"]
}, null, 512 /* NEED_PATCH */)

What is expected?

I expected the generated code to fulfill TypeScript type constrains.

What is actually happening?

The type for the second argument of createVNode is (Data & VNodeProps) | null, and the type of ref property of VNodeProps is string | Ref | ((ref: object | null) => void).

This means the code generated by the template explorer does not fulfill TypeScript type constrains, because ref is defined as [_ctx, "modal"], which does not satisfy its corresponding type definition.

---

I don't know if the solution is to expand the ref property type definition, or to adapt the code generator, or even if this is really an issue.

[jbruni]

The array syntax for ref is not an issue when used in createBlock, because props type is defined as { [key: string]: any } | null...

Now I see :thinking: ...

It looks like createBlock's props argument type should be updated to Data | null, to be closer to createVNode's props argument type... or even to (Data & VNodeProps) | null, so both are equal... and the change must be done to the ref type in VNodeProps, to allow the array interface...

I really don't know. I am only wondering aloud. TypeScript is new to me.

[yyx990803]

I did some refactor to remove the need for the special case.