Please, don't let the Options API become a second-class citizen

[rodrigocfd]

As the time goes on, the Options API seems to be more and more abandoned.

• Typing props is so annoying when compared to the more polished Composition API.

• And it gets worse: in generic components, props must be declared twice, in addition to mix some Composition API inside the Options API declaration.

• Typing emits also feels very clunky.

Please don't forget that Options API is what made Vue famous in the first place. It's such an unique construction among the frameworks. It's so efficient in enterprise environments, where code switches from team to team and code organization is a must.

Please, don't let the Options API become a second-class citizen.

[Alfred-Skyblue]

1. So far, Vue has continued to support the Options API and has not abandoned its maintenance. You can still use it in your projects.

2. If the majority of developers prefer using the Composition API in their projects, it precisely demonstrates that it better aligns with developers' usage habits.

Vue has consistently been exploring user habits, not stagnating on the Options API but constantly evolving, improving, and delivering a better development experience. This is a positive phenomenon rather than a negative one, isn't it?

[LinusBorg]

One of the things that made us introduce Composition API (and likewise, the previously discussed but abandoned idea of a class-API) in the first placewas that it's very hard to provide full TS support for the options API, and some things are de facto impossible.

Using TS with Options API feels clunky because it doesn't play well with TS, for the most part, and also because we can't do some things that we do in script setup to keep things backwards-compatible - not becaus we don't care.

Still, we did improve the TS support for Options API in Vue 3 compared to Vue 2, but some things will always feel clunky or be unsupported, because of that inherent mismatch.

[pikax]

As the time goes on, the Options API seems to be more and more abandoned.

Where do you get this from? I actually have gone to great length to support Options API in types #9556

Typing props is so annoying when compared to the more polished Composition API.

Declaring props is the same as composition-api, the only time is different is script setup, which by it's nature allows us to modify and infer certain types, aside from that, there's no differences between APIs.

And it gets worse: in generic components, props must be declared twice, in addition to mix some Composition API inside the Options API declaration.

Generic components are difficult to get it right, my personal recommendation is just targeting the component public API (props, slots, events) to be generic instead of the component definition being generic. Based on that Options API and Composition is the same in terms of typing.

Typing emits also feels very clunky.

I type emits using options API, since I don't like the type based declaration, this is personal and I don't know what you mean by "clunky".

---

I guarantee in terms of types Options API has not been forgotten/abandoned nor deprecated.