How should strictTempaltes compiler option be used?

[nayakunin]

Hi. I've just recently starting working with Vue coming from the React world. I've gotten used to full type safety, that can be achieved there and I've been quite surprised when I saw that the strictTemplates tsconfig compiler options is not enabled by default. Using the strict: true option in React never caused any issues for me. I've tried enabling it on a real project, and I immediately saw a bunch of errors. Here is an example of such error:

<SomeComponent id="something" />
// Object literal may only specify known properties, and 'id' does not exist on ...

The id used in this component is not defined in the props and relies on the fallthrough attributes feature. The issue is that Vue doesn't automatically infer the type of the fallthrough attributes, though there is a compiler option that enables that. I've tried using it, but quickly found out that it only actually infers the types of the variable attributes, like an id, but it doesn't infer the types of callbacks. An example with enabled fallthroughAttributes:

// component.vue
<script setup lang="ts">
type Props = {
  something?: string;
};

defineProps<Props>();

type MyData = {
  id: number;
  name: string;
};

const emit = defineEmits<{
  (e: "click", data: MyData): void;
}>();
</script>

<template>
  <div class="A" @click="emit('click', { id: 1, name: 'name' })">text</div>
</template>

// app.vue
<script setup lang="ts">
import Component from "./component.vue";
</script>

<template>
  <Component @click="console.log" @mouseenter="console.log" /> // Object literal may only specify known properties, and 'onMouseenter' does not exist in type ...
</template>

I've looked for a solution, how the fallthrough attributes can be properly typed an encountered these discussions:

• https://github.com/orgs/vuejs/discussions/10262
• Infer attrs for implementing HOCs rfcs#479

There is a solution in the first discussion that would solve my problem https://github.com/orgs/vuejs/discussions/10262#discussioncomment-8354644, but it seems quite cumbersome and it seems like I'm fighting the compiler. Here is the code for that:

interface Props extends /* @vue-ignore */ ButtonHTMLAttributes {
	foo: string
}
const _props = defineProps<Props>() // this makes sure consumers see the button attributes in autocomplete
const props = _props as Omit<typeof _props, keyof ButtonHTMLAttributes> // this cleans up the props type
const attrs = useAttrs() as ButtonHTMLAttributes // and this casts the attrs object to something matching the allowed fallthrough attributes

So the question is, is it ever a good idea to enable the strictTemplates feature? If you are relying on a component library that doesn't properly type its fallthrough attributes, you seemingly would never be able to use that. I've looked around how other component libraries deal with this issue and found out that some of them don't add types for the attributes, while some others, like prime-vue, have a separate .d.ts file with the extends ButtonHTMLAttributes declaration, where they are not required to use the @vue-ignore statement. Is the approach the prime-vue uses the only viable approach to be taken? A small example:

<script setup lang="ts">
import Button from "primevue/button";
import { CheckboxRoot } from "radix-vue";
</script>

<template>
  <Button
    label="Get Started"
    class="p-button-raised p-button-rounded"
    id="sss"
    @mouseenter="(e) => {}" // (parameter) e: MouseEvent 👍 
  />
  <CheckboxRoot @mouseenter="(e) => {}" /> // Object literal may only specify known properties, and 'onMouseenter' does not exist in type 'NonNullable<Partial<{ value: string; as: Component<any, any, any, ComputedOptions, MethodOptions, {}, any> | AsTag; checked: boolean | "indeterminate"; }> & Omit<...>>'.
</template>

Are there any real world projects that actually use this feature successfully, and if they do, then how do they deal with the un-typed attributes issue?

Just for a reference, this is an example, of what I'm trying to achieve in React code:

interface Props extends React.ComponentProps<"div"> {
  something: string;
}

export const Component = ({ something, ...props }: Props) => {
  return <div {...props}>{something}</div>;
};

And a more realistic one:

import { Slot } from "@radix-ui/react-slot";
import * as React from "react";

interface BreadcrumbLinkProps extends React.ComponentPropsWithoutRef<"a"> {
  asChild?: boolean;
}

const BreadcrumbLink = ({
  asChild,
  className,
  ...props
}: BreadcrumbLinkProps) => {
  const Comp = asChild ? Slot : "a";

  return (
    <Comp
      className={cn("transition-colors hover:text-neutral-950", className)}
      {...props}
    />
  );
};

[KazariEX]

The above example doesn't work due to two current bugs in the language tools. First, you need to use a name other than Component to use that component. Second, defineModel or defineEmits cannot be used inside that component. The first issue has been resolved in the latest commit, but the second one is a bit tricky.

[KazariEX]

When fallthroughAttributes is enabled, a component may receive all attributes of its root node, including many native onXxx event handlers. If the component also uses defineEmits to define events with the same names as these native ones, the inferred property types will intersect with the native event types, potentially causing type errors. Therefore, we are currently excluding these onXxx events from the inherited native attributes to avoid such issues.

At this point you could do this to make all components inherit all basic HTML attributes by default:

declare module "vue" {
    interface AllowedComponentProps extends HTMLAttributes {}
}

[nayakunin]

I see, thanks for the explanation. It makes sense now why only the regular props show up with fallthroughAttributes: true.

At this point you could do this to make all components inherit all basic HTML attributes by default:

declare module "vue" {
    interface AllowedComponentProps extends HTMLAttributes {}
}

Well, not really. I agree that it would solve most of my problems, but in some cases where I'd need more specific attributes, I'd still need to do the same stuff with @vue-ignore and extends. Like let's say I'd do something with the <a> tag. It has its own specific properties, like the href. I'd still have to define it in the same way i showed above.

The documentation regarding the fallthroughAttributes compiler option says that it has a quite significant performance impact on the TS compiler performance. Would you be able to clarify how big is the performance hit actually? Is it feasible to turn this on in a project with ~100 devs working on it full time (I don't know how to give a better size estimation).

Regarding your suggestion for the global extends from HTMLAttributes, is this something that you would ever do in your projects? Would you consider using strictTemplates and whatever you answer is, why?

[KazariEX]

The documentation regarding the fallthroughAttributes compiler option says that it has a quite significant performance impact on the TS compiler performance.

Its performance impact comes from deeply nested components potentially having long chains of attribute inheritance, but that may not be the core issue. Also, since our investigation back then, there have been several optimizations to virtual code generation. You can try toggling the fallthroughAttributes option and triggering completion in the template of a component where the option takes effect to see if there is a noticeable difference in IntelliSense performance.

Regarding your suggestion for the global extends from HTMLAttributes, is this something that you would ever do in your projects? Would you consider using strictTemplates and whatever you answer is, why?

I don’t do that — in my projects, I typically disable checkUnknownEvents (while enabling most strict options and fallthroughAttributes). I generally avoid fallthrough native events on highly abstracted components and prefer to define them explicitly instead. Even in cases where the native event types are lost due to the limitations described above, we still need to explicitly annotate the event type when declaring the handler function. As for type safety, I think we can only rely on code review.

[nayakunin]

Its performance impact comes from deeply nested components potentially having long chains of attribute inheritance, but that may not be the core issue. Also, since our investigation back then, there have been several optimizations to virtual code generation. You can try toggling the fallthroughAttributes option and triggering completion in the template of a component where the option takes effect to see if there is a noticeable difference in IntelliSense performance.

Got it. Will do.

Even in cases where the native event types are lost due to the limitations described above, we still need to explicitly annotate the event type when declaring the handler function.

<script setup lang="ts">
import SomeComponent from "./SomeComponent.vue";
</script>

<template>
  <SomeComponent @mouseenter="(payload: MouseEvent) => console.log(payload)" />
</template>

When you say we still need to explicitly annotate the event type when declaring the handler function you mean this, right? Declaring the type of the event explicitly in the place where it is used.

I generally avoid fallthrough native events on highly abstracted components and prefer to define them explicitly instead.

I agree that this is a decent solution in application code, but It seems like this is not a feasible approach when building a component library. Declaring every single callback & prop explicitly would require a bunch of code, that technically is not even needed there. If you were to build one, what approach would you take? Would you look for a way to provide proper types for fallthrough attributes or would you just not invest any time into that?

Another question: is fallthrough attributes usage discouraged? You just said yourself that you are avoiding them whenever possible and I see why, the issue with types is quite obvious. Just based on your personal experience, would you say that your opinion regarding this feature is reflected in the Vue community?

[KazariEX]

If you were to build one, what approach would you take? Would you look for a way to provide proper types for fallthrough attributes or would you just not invest any time into that?

I think this requires core to cooperate (rfcs#479).

You just said yourself that you are avoiding them whenever possible.

I mean just native events. If the wrappers are simple enough, there's nothing wrong with using them.

Would you say that your opinion regarding this feature is reflected in the Vue community?

No, that's just my opinion.