Can 'defineProps' be used independently for each prop?

[yogeshgalav]

One of the major change in vue2 to vue3 migration was to separate the data() properties,
So that they can be better typed and reusability using ref() or reactive().
But I don't know why this is not the case with props and emits.
They are still written at one place, cluttering the code.
And for better typescript support they made code somewhat more complex.

Is it not possible to write props and emits separately?

let ref_msg = ref<string>('Hello World!');
let msg = prop<string>({default: 'Prop Msg', type: String});

[quiteeasy]

I'm wondering why you believe using props across the entire script would be a cleaner approach instead of defining them in one place?

[yogeshgalav]

@quiteeasy
You can consider why we separated data(), computed, methods, watch in vue3? Isn't that major change being for a reason?

First of all it gives better typescript support,

• defineProps with ts isn't that readable
• we have to write name and type of props 2 times, in normal js we don't have to do that.

Second reason is separation according to usability

• I have table component with uses some css props, some props related to rows and some props related to columns. I wish to define them only above method or computed property in which they are used.

Third reason is de structuring overhead

• Although, de structuring of props is now possible with toRef but it's still overhead and lead to writing prop name 3 times.

Above solution will make things much easier to read and understand.

[quiteeasy]

The Composition API was introduced in Vue.js for several reasons, including better code organization, better TypeScript support, and more flexibility. According to the official Vue.js guide (https://vuejs.org/guide/extras/composition-api-faq.html#why-composition-api), the Composition API separates concerns, making it easier to organize and reuse code logic.

One advantage of the Composition API is improved TypeScript support. With the <script setup> syntax (https://vuejs.org/guide/typescript/composition-api.html#using-script-setup), you can define props using TypeScript interfaces without providing runtime definitions, which enhances type safety.

Additionally, the Composition API promotes a cleaner approach to defining reactive values and more flexibility. Instead of declaring them right before usage, you define them in a centralized location, typically at the top of the component, right? This centralized definition promotes better code organization and maintainability. The same for props, it is more readable if they are in one place.

[yogeshgalav]

@quiteeasy
Check this,
https://github.com/bootstrap-vue-next/bootstrap-vue-next/blob/main/packages/bootstrap-vue-next/src/components/BTable/BTable.vue
I don't think the props in above component is refers to clean code, is readable, has better typescript.
Would it be great idea to keep all refs, computed in centralized location? If no, then why be racist with props and emits?

[quiteeasy]

Regarding the approach to handling props, an alternative to splitting them as singles with prop() as described could be to use the toRef() function before the usage of a prop. This can be particularly beneficial for large components like the one provided, spanning over 1000 lines of code.

While splitting props can be a valid approach, defining them in a centralized location often leads to better organization and maintainability, especially for components of such scale. Keeping props in a single place, rather than scattered throughout the codebase, can improve readability and make it easier to manage and update them as needed.

By utilizing toRef() and defining props centrally, we can strike a balance between keeping the component code clean and organized, while still benefiting from the reactivity and convenience provided by Vue's composition API.

I am wondering why you consider TS support to be poor? and what do you mean by has better typescript?

[yogeshgalav]

vuejs/rfcs#513