urql

urql copied to clipboard

Summary

Some people would prefer to keep using the Options API instead of the alternative Composition API.

The Options API, as opposed to the Composition API, is the original way of creating Vue apps and components which can be found all over the docs, in which an options object is passed to the Vue constructor, or exported in the case of Single File Components.

Proposed Solution

A way to use urql using the declarative Options API in addition to the existing Composition API. The API could look something like the vue-apollo API

Could you elaborate on what the options api is, how an implementation would look like and so on? This isn't really an RFC rather than a request. Other issues tagged with future could serve as an example.

It was not my ambition to create a RFC, just a feature request. However this was the closest template which fitted the feature request case.

With that out of the way, the Options API as opposed to the Composition API, is the original way of creating Vue apps and components which can be found all over the docs, in which an options object is passed to the Vue constructor, or exported in the case of Single File Components.

vue-apollo is an example of what supporting the Options API could look like https://apollo.vuejs.org/guide/apollo/#usage-in-vue-components

I'm wondering however, would it make sense to still provide an Options API if Vue 3 shows the Composition API front and centre. Our ambition was to support mostly Vue 3and this seemed to be the more idiomatic approach of the two at least there. cc @LinusBorg: Do you have any insights on whether it'd be necessary or make sense to support both?

My understanding is that:

1. The majority of the docs is written with the Options API
2. There is a section in the docs for the Composition API
3. There is no intention to deprecate the Options API
4. The Composition API is not touted as the successor to the Options API, but as an alternative

That's pretty much spot on on. the fact that the composition API right now take so much of the spotlight is just stemming from the fact that it's new and exciting.

It does solve real problems in areas of abstraction, composition and reusability, but the main API people are familiar with, and many/most new people probably pick up first, is still the Options API that remains largely unchanged from Vue 2.

So in that light it would be great if it would be supported. It should be possible to achieve it in a way that adds little overhead and uses the existing use* functions under the hood - I'll take a look, might take a bit though.

@kitten Could you share some context on the hold ⚠️ tag? Thanks!

Closing as not planned.

I know this is controversial, but our whole opinion on this was to wait out and see whether we a) could implement this cleanly, and b) whether adoption of Vue 3 would pick up fast enough.

We've seen that it's reasonably fine to adopt, and that the Options API wouldn't live up to our standardds, both in implementation and usability.

Sorry! :sweat_smile: