Things that will improve Vue DX 💯

[sadeghbarati]

First of all thanks to the Vue team for their hard work on core and core-vapor ❤️🙏

---

While I was contributing to shadcn-vue, and checking other ports like shadcn-ui, shadcn-svelte, and solid-ui,
I realized Vue was missing some features like

• Extending Complex Types (entire type object) which is not yet supported in SFC files
  • How to "extend" component props & emit types when Fallthrough Attributes? core#9906
  • Make runtime Props validation optional rfcs#549
  • https://github.com/guilhermerodz/input-otp/blob/feat/multi-frameworks/lib/vue/types.d.ts#L7 (/* @vue-ignore */ )

• Component Type Helper
  • https://www.totaltypescript.com/react-component-props-type-helper
  • types(defineComponent): Stricter Component Type + helpers core#9556
  • https://github.com/vuejs/language-tools/tree/master/packages/component-type-helpers

• Remove undefined boolean casting to false it should be undefined when it's not defined
  • Minor bug with Boolean props casting: undefined => false vue#4792 (comment)
  • https://x.com/slava_trushkin/status/1760570401342595553?t=cnlxDNnu61Z5Glkjkkxr1w&s=33

• Reactive Props Destructure
  • [Core Team RFC] Reactive Props Destructure rfcs#502 (comment)

• ref as forwardRef instead of componentRef.value.$el for Component Instance that don't expose anything
  • Add forwardRef API to make it possible let component handle ref itself rfcs#258 (comment)
  • https://twitter.com/acdlite/status/1719496241501847884?t=A3qNDupM9tnJq7mRG589pg&s=19

Thanks for your time 👍

[zernonia]

Good list of features @sadeghbarati . Might not be directly related to Vue Vapor, but I think it's a great improvement for Vue in general 👍🏻

[productdevbook]

We wrote TS at the beginning of Oku Primitive because of these problems. We wrote TS because we couldn't figure out how to solve it in SFC and there was no SFC support among the supporters (actually, someone knew, hid himself, went and installed radix-vue. 😂). The biggest problems here were the same for Oku Primitive.

It would be great if these issues could be resolved. These are good topics for the ecosystem. @sadeghbarati I agree. these are important topics.

[sxzz]

Thank you for your suggestion. In Vue Vapor, our plan is as follows:

• Unfortunately, Vue Vapor is not a platform for introducing breaking changes. It's meant to be a subset of Vue, meaning we only implement features from the Vue core that we believe are worth including in Vue Vapor. Features like the Options API might not be introduced in Vue Vapor.
• However, regarding internal implementation, we believe there is room for improvement. Especially if we decide to drop support for the Options API, types could be greatly simplified. At the very least, we can optimize types for Composition API.
• If we want to introduce a new feature, Vue Macros should still be our first port of call. Our plan is: Might implement the new feature in Vue Macros first. If it receives positive feedback, then an RFC can be proposed. If this feature gets exceptionally good feedback, we would consider implementing it early in Vue Vapor and marking it as experimental. After finalization, it would then be ported to the core of Vue.

Lastly, thank you again for your suggestion. Most of your suggestions align with my personal thoughts as well; hence the creation of the Vue Macros project. But currently most of my energy is focused on Vue Vapor; thus at present time there may not active maintenance on Vue Macros (if there are maintainers willing to put forth effort together I am also very happy to accept).

[Saeid-Za]

Thanks for your detailed response !

• Regarding the dropping support for Options API, Is this confirmed? or a possibility for now?
• I do think some of the suggestions here could be implemented as a macro and then be validated naturally in the process you described.
  • "Remove undefined boolean casting to false it should be undefined when it's not defined" -> (boolean to Boolean workaround)
  • "Reactive Props Destructure" is already supported by a macro (or flag)

But I don't think a macro could fix the following items:

• "Make runtime Props validation optional #549" -> Still in RFC Process, No Update
• "Component Type Helper" -> Still in PR Process, No Update and still has errors, current impl has issues too

What is the process for these two items?
Thanks in advance !

[sxzz]

We have not yet decided on dropping support for the Options API. Initially, we will only support the Composition API and then decide whether to add support for the Options API based on community feedback. We'll also consider making the Options API an additional library that requires manual installation.

Vue Macros doesn't just accept macros; it also supports other features, including some behaviors that hack into the runtime.

---

Make runtime Props validation optional #549
Component Type Helper

If we were to implement this feature, it would be applicable not just to Vapor but also to Vue core. Therefore, as I mentioned, advancing it is not solely Vapor's task but a separate and universal effort.

[sadeghbarati]

I appreciate the explanation @sxzz

vuejs/rfcs#528

Unfortunately, Vue Vapor is not a platform for introducing breaking changes

As long as Breaking Change can Save Time I would like to have it, saving more time and make it simple for Vue dev, more contribution Vue org repos will get

We have not yet decided on dropping support for the Options API

I'm afraid it's not possible in the near future cause I set __VUE_OPTIONS_API__ flag to false in vite.config and the my Vue app stopped working cause some of packages I used was mixed with Option API and Composition API, those packages was made with vue-demi to make it Compatible with older version of Vue, I liked vue-demi idea back then but now I prefer to target to only Vue 3 and Composition API syntax

Please take a look at the 'dist' directory, I could have contributed to the Vue community when I spent making my package compatible with older version of Vue.
https://www.npmjs.com/package/@smooth-scrollbar-contrib/vue-test?activeTab=code

Dropping Option API also help all Vue maintainers and Vue devs to focus on ONE friendly syntax script setup and Composition API

[sxzz]

I want to emphasize that it's not that we don't accept breaking changes. Through the solutions mentioned above, we still have the opportunity to introduce breaking changes. However, Vue Vapor was designed from the beginning as a subset of Vue core.

If you want your app to run in Vue Vapor, then we have no choice but to stick with the APIs provided by Vue Vapor.

Of course, in the future, we will also enable Vapor mode for certain component. For components that are sensitive to performance, it makes sense to activate Vapor and use only a limited set of APIs.