TypeScript error when forwarding ctx.attrs to child component via h()

[prince-kunwar-xcelore]

I’m running into a TypeScript issue when trying to forward ctx.attrs from a wrapper component into a typed child component using h().

Reproduction

import { defineComponent, h } from 'vue';

// A typed child component with declared props
const Child = defineComponent({
  props: {
    name: { type: String, required: true as const },
    label: { type: String },
  },
  template: `<div>{{ name }}</div>`,
});

// A wrapper that tries to forward ctx.attrs into h()
export const Wrapper = defineComponent({
  inheritAttrs: false,
  setup(_, ctx) {
    return () => {
	// Actual: ❌  —
	//   Argument of type 'Data' is not assignable to parameter of type
	//   '... & { $: ComponentInternalInstance; $data: {}; $props: ... }'
      return h(Child, ctx.attrs);
    };
  },
});

I'm not sure how I would resolve this, any ideas?

[aniruddhaadak80]

@shubph The issue is that h() expects exact prop matches, and ctx.attrs is often typed loosely as Data or Record<string, unknown>.
To satisfy TS without suppressing everything:

return h(Child, ctx.attrs as any); 
// or simpler in setup:
return () => <Child {...(ctx.attrs as any)} />

Since you are disabling inheritAttrs, you are taking manual responsibility, so the cast is safe/expected here.

[mg1986jp]

[prince-kunwar-xcelore]

Thanks, this is helpful. A few thoughts:

Option 2's code is actually identical to Option 1 in substance. It's the same ctx.attrs as ...InstanceType<typeof Child>['$props'] cast, just with an extra as unknown in between. The heading mentions Vue 3.3's generic components feature but the snippet doesn't actually use it (no <script setup generic="..."> or generic type parameter), so it's really just a restatement of Option 1.

Option 3 isn't really solving the typing problem either. It just lets me pick which attrs to forward, which is only a benefit if I care about not polluting the child with unwanted attributes. For pure attribute forwarding it adds verbosity without buying type safety I didn't already have from Option 1.

On the underlying issue: you're right that ctx.attrs is typed as Record<string, any> and therefore isn't assignable to the child's props, because at the wrapper's definition site we don't know what attrs will actually arrive. But that's exactly the limitation I'm pointing at. Ideally defineComponent would let me declare the wrapper's accepted prop types, something like ChildProps & AdditionalProps, and then ctx.attrs would be typed as that intersection. Since that intersection is a subtype of ChildProps (it has all of Child's required props plus more), it would be assignable to the child without any cast. The cast in Option 1 is fine in practice, but it feels like papering over a gap in the API rather than a fundamental type-system constraint.

Appreciate you walking through the options though, Option 1 is what I'll go with for now.

[mg1986jp]

Sorry about the empty comment — accidentally deleted my original answer.

You're right that Options 2 and 3 were just the same cast with extra steps, should've kept it simple. The real issue is what you said — defineComponent has no way to declare what attrs a wrapper accepts, so ctx.attrs stays loosely typed. Your intersection type idea would be a clean solution if Vue ever supports it.

Glad Option 1 works for you.

[wyf027]

ctx.attrs cannot be inferred as the child's props here. It is deliberately loose (Data / Attrs) because it may contain fallthrough attrs, class / style, listeners, and anything the wrapper itself did not declare. From TypeScript's point of view, there is no guarantee that ctx.attrs.name exists or that the values match Child's props.

So the cleanest fix depends on what contract you want for the wrapper.

If Wrapper should expose the same public props as Child, share/declare those props on the wrapper and forward typed props:

import { defineComponent, h } from 'vue'

const childProps = {
  name: { type: String, required: true },
  label: String,
} as const

const Child = defineComponent({
  props: childProps,
  template: `<div>{{ name }}</div>`,
})

export const Wrapper = defineComponent({
  props: childProps,
  inheritAttrs: false,
  setup(props, { attrs }) {
    return () => h(Child, { ...attrs, ...props })
  },
})

That makes name / label part of Wrapper's public API, so TS can check callers of the wrapper instead of trying to recover the type from attrs.

If the wrapper is intentionally transparent and you want to delegate whatever came in through attrs, then a type assertion is the correct boundary. I would still avoid as any and assert the intended public prop type instead:

import type { ExtractPublicPropTypes } from 'vue'

type ChildPublicProps = ExtractPublicPropTypes<typeof childProps>

return () => h(Child, ctx.attrs as ChildPublicProps)

That cast is basically saying: "this wrapper does not validate these props; the child does." The fully type-safe version is the first approach, where the wrapper declares the props it accepts.