TS: defineComponent doesn't return a Component

[jods4]

Version

3.0.0-beta.2

Reproduction link

https://codesandbox.io/s/amazing-meitner-tgk24?file=/src/main.ts

Steps to reproduce

See main.ts in repro.

I'm having typing issues with defineComponent once more, it seems to me the root cause is that defineComponent TS definition pretends to return a ctor when it does not.

This time the offender is Component: a union type that includes both stateful and functional components but not ctor, which would be ok if defineComponent wasn't lying about its return type.

Out of curiosity, I looked at how createApp manages to do it: its first argument is a PublicApiComponent, which turns out to be... the union of Component and Ctor!
This is just confusing, not to mention PublicApiComponent is not exported, so there's no type in Vue API that can be used to describe a "component" type that would work in all cases.

What is expected?

Code should compile? Or a good alternative be provided?

What is actually happening?

TS error as Ctor is not a Component.

[pikax]

From what I've learned, defineComponent return ctor is actually an hack to make h do some validations.

I've done also an hack to make defineComponent return an Component valid. After sleeping over my solution, still not happy with it, personally I think having PublicAPIComponent as the public type component would be better and use Component to more internal type, this would require some name change.

[jods4]

@pikax that's fine, I figured there had to be a reason why defineComponent isn't returning the real type.

From a public API perspective, can I suggest that you do a bit of renaming type? Can Component be the public, usable type (i.e. the current PublicAPIComponent); and the current Component becomes some CompositionComponent or whatever and we make sure that it's never exported in public api surfaces?

[pikax]

Even with the rename it makes really hard to enforce the correct types validation, because when you have the interface Component that is generic, the enforcing of the props becomes really hard.

The tests I was getting trouble with were the h-dts

if we are too loose, this will not pass

describe('h inference w/ Fragment', () => {
  // only accepts array children
  h(Fragment, ['hello'])
  h(Fragment, { key: 123 }, ['hello'])
  expectError(h(Fragment, 'foo'))
  expectError(h(Fragment, { key: 123 }, 'bar'))
})

making the it too strict will make this fail

// #922
describe('h support for generic component type', () => {
  function foo(bar: Component) {
    h(bar)
    h(bar, 'hello')
    h(bar, { id: 'ok' }, 'hello')
  }
  foo({})
})

Because we want prop typescript validation, we can't be too loose on the validation.