Allow assign all attributes as props

[pikax]

Discussion Thread for "Allow assign all attributes as props"

Links

• RFC Proposal
• Full Rendered Proposal

[jods4]

Maybe it's because I'm not familiar enough with React but I don't understand the Motivation section.

I find this proposal confusing (as acknowledged in the Drawbacks section) and I don't get what the benefits or use-cases are.

Could you provide a bit more context or give an example of some use-case that would be better with this RFC?

[pikax]

I'll improve the wording tomorrow but the gist would allow you to lean heavily on typescript for validation (similar to functional components), instead of relying on vue props definition (for runtime validation).

interface ComponentProps {
  test: string
}

defineComponent<ComponentProps>({
 setup(props){
   expect<ComponentProps>(props)
 }
})

Use cases are the ability to define the prop types for the components without defining the prop object - which is a bit trickier for users to generate with the automated tools that generate typescript definitions for endpoints.

[jods4]

If I understand correctly I totally agree with you on the issue: defining props in typescript is not a good dev experience.

I don't think making an alternative way to do the same thing is the right move, though. I'd rather that we fix the props problem directly.

By hijacking the attrs concept, I find that this PR might create confusion. On the other hand, it doesn't solve the props problem completely.

There's a reason that both attrs and props exist as distinct concepts. If I'm writing a component that needs to inherit attrs and define a few props in Typescript, my understanding is that this RFC won't help.

I said before that I find the new way to declare props in script setup much more pleasing for TS users and I that I wished it could be back-ported to the traditional style as well.

I guess the main roadblock today is that classic <script> blocks are not processed at all by a Vue loader. They're straight compiled to code without introspection and all behavior is then defined at runtime by its exports.

Would it be so bad if Vue actually looked at the code like it does for script setup. If it did we may get away with stuff like:

interface Props {
  firstName: string;
  middleName?: string;
  lastName: string;
  age: number;
}

export default defineComponent<Props>({
  // props automatically defined based on typing
  setup(props) {
    console.log(props.firstName)
  }
})

or instead of a loader maybe that could be accomplished by a TS plugin? It's a TS-only enhancement so it doesn't need JS support.

[pikax]

If I understand correctly I totally agree with you on the issue: defining props in typescript is not a good dev experience.

Is possible, but not a good experience.

By hijacking the attrs concept, I find that this PR might create confusion. On the other hand, it doesn't solve the props problem completely.

That's the design implementation, explanation :

In vue everything declared in the props object will be bound to the component instance, allowing the direct access in the template (without $props. prefix), everything else will be added to $attrs object.

There's a reason that both attrs and props exist as distinct concepts. If I'm writing a component that needs to inherit attrs and define a few props in Typescript, my understanding is that this RFC won't help.

This RFC doesn't aim to do that, for that you would be required to specify vue props, because that's a runtime behaviour, cannot be achieve by typescript, please check supporting interface props PR. For that use case you won't be using this RFC proposal, because you need props and attrs.

I said before that I find the new way to declare props in script setup much more pleasing for TS users and I that I wished it could be back-ported to the traditional style as well.

This RFC doesn't target script setup way, this RFC will handle the defineComponent API.

I guess the main roadblock today is that classic <script> blocks are not processed at all by a Vue loader. They're straight compiled to code without introspection and all behavior is then defined at runtime by its exports.

Might be some misunderstanding here (my initial RFC was confusing, and I apologise, please can you check it again, probably is a bit more better), altho the main advantage is to improve the Typescript usage, this also helps users who just want to prototype something quickly:

const Comp = defineComponet({
  props: false,
  template: `<div>{{name}} {{surname}}</div>`
})

defineComponent({
 components: { Comp },
 template: `<comp name="test" surname="other" />`
})

There's no need to force the users to describe all the props. This is the reason why the $attrs needs to be hijacked, because this behaves differently from the other components, maybe the rule would be everything is assigned to props instead of attrs.

[jods4]

vuejs/core#3049 doesn't remove the need to declare the props as a component property, right?
What would be lovable is vuejs/core#3049 without the need for a redundant props property.
I understand that it would require a loader or a TS plugin because Vue runtime depends on this props declaration and types can't generate code.

With this the TS DX would be much better and it would achieve a similar goal as this RFC.

this also helps users who just want to prototype something quickly

That's actually easy to do today without any modification to Vue core:

const Comp = defineComponent({
  inheritAttrs: false,
  setup(_, { attrs }) { return attrs },
  template: `<div>{{name}} {{surname}}</div>`
})

[pikax]

vuejs/vue-next#3049 doesn't remove the need to declare the props as a component property, right?

No, it's just an extra step to guarantee the props are correct.

I understand that it would require a loader or a TS plugin because Vue runtime depends on this props declaration and types can't generate code.

With this the TS DX would be much better and it would achieve a similar goal as this RFC.

I don't think we should rely on a plugin, because this can be used with vanilla JS, that's why having the constructors, would provide some type inference.

That's actually easy to do today without any modification to Vue core:

const Comp = defineComponent({
  inheritAttrs: false,
  setup(_, { attrs }) { return attrs },
  template: `<div>{{name}} {{surname}}</div>`
})

But you don't get the typescript types there. Functionality wise would be similar to that but with the type declaration and passed to defineComponent.

[jods4]

I don't think we should rely on a plugin, because this can be used with vanilla JS, that's why having the constructors, would provide some type inference.

I'm not implying that the plugin would be the only way.

Vanilla JS doesn't have types at all, so it can just use the props that we have today.

TS would benefit from using its typing system to define the props (and maybe a plugin generates the required runtime property). The current way is a bit clumsy in TS today.

But you don't get the typescript types there.

Neither did you in your "quick prototyping" example.

[pikax]

Vanilla JS doesn't have types at all, so it can just use the props that we have today.

You still get some types when using props when using vanilla JS, because when you use VSCode it will still rely on typescript provided by the lib:

import {defineComponent} from 'vue'

defineComponent({
  props: {
    test: String
  },
  setup(props){
    props.
  }
})

I would expect the same behaviour when using the this RFC without typescript (with Object syntax similar to props declaration).

Neither did you in your "quick prototyping" example.

That's one of the examples, but when the user has the type/interface, cannot pass as an attribute type unless it casts on the return of the setup, which is not really user friendly and a bit confusing because if you want to use the options API you should be able to have the same behaviour

[enpitsuLin]

can we make components with non defined props automatically assign $attr as $prop?
This may also solve the problem of the difficulty of defining generic types of props( PropType is not too elegant)

[westbrma]

can we make components with non defined props automatically assign $attr as $prop? This may also solve the problem of the difficulty of defining generic types of props( PropType is not too elegant)

That is basically what I was proposing here: [https://github.com/vuejs/core/issues/5730]

[enpitsuLin]

The way Vue runs now inevitably requires runtime Props making it very difficult to define Props using generics out SFC, but the team doesn't seem to see this as a high priority

I think the compromise is to provide compile-time behavior similar to defineProps to allow defineComponent<P>(setupFunction) to work as intended without props option

[westbrma]

when you create a functional component, all the props work without explicitly specifying them. you can simply do

const comp = p => {
      return ()=><div>{p.name}</div>
}

so I do not know why it would take much effort to also have this behaviour with defineComponent when passing a setup function

[Heniker]

Unfortunately functional components are not reactive in the same way as normal components are reactive. Functional components will trigger full re-render on any state changes (and you actually can't return function from functional component - only plain VNodes).

[rdhelms]

I think the TS experience with the Options API could be hugely improved with this change. If users could opt out of component props runtime validation, then TS and Volar would handle all we need.

See vuejs/core#7832 and https://github.com/vuejs/core/issues/7833

[mrhammadasif]

Why not just make a defineOptionalProps function instead of noProps: true property

[Heniker]

This needs to see more support. Typing/declaring props always feels really awkward. I found at least 1 2 3 libraries (not even mentioning defineProps way) that aim to simplifiy this process, which is 3 libraries too many for such simple action.

I would love to use something like this:

v.defineComponent({
  setup(
    props: MyProps,
    ctx: SetupContext<
      MyEmits,
      SlotsType<MySlots>
    >
  ) {}
})

which seems to type-check fine RN, but props are not correctly passed to such component during runtime.

[ferferga]

I'm 100% onboard this. In my opinion, this is the major limitation that we have right now to properly support TypeScript and I've seen confusion between the Vue way and TypeScript way (see first and last code snippet here, respectively).

The caveats/differences between every macro are also becoming more problematic. And there's also a defineAttrs proposal. It's becoming more and more difficult to track all the macros