Vue3 support

[bjarkihall]

Hi, I just didn't want the idea to get lost: https://twitter.com/tannerlinsley/status/1275820844745281538
Vue3 is still in Beta but I like the idea of hooks libraries to be available between view libraries and react-query provides intuitive abstraction over caching server data.

I'm also interested if the same can be said about other Tanstack libs, since they are React hooks based - is the main logic usually abstracted in a way one could easily swap out the hooks themselves with an alternative or is this just the case with react-query?

For a quick summary here's React Hooks comparison with the Composition API:

Basic Hooks

• useState -> Vue's reactivity model tracks mutable changes via ref(0) (primitives) and reactive({count: 0}) (e.g. objects) and they can be transformed back and forth.
• useEffect -> Vue's hooks are only executed once (unlike React) so you can subscribe to changes via watchEffect(()=>console.log(count.value)) or lifecycle hooks (onMounted, onUpdated, onUnmounted and some more). Vue also has watch(count, (count, prevCount) => console.log(count, prevCount)), to track specific variables lazily and have access to prev/current values. Note that you don't need to specify dependency arrays since they are automatically tracked.
• useContext -> Vue has provide(key, optionalDefaultValue) in the Context provider and the hook inject(key, optionalDefaultValue) in the consumer. The value can be reactive and the key can be string or preferably a symbol.

Additional Hooks

• useReducer -> not needed since the reactivity model is mutable.
• useCallback -> not needed since dependencies are automatically tracked.
• useMemo -> not needed since dependencies are automatically tracked.
• useRef -> const x = ref(0) returns a reactive object with the value accessible (read/write) through x.value += 1. You're also not limited to primitives. Refs are also used for DOM element references in the same way as React.
• useImperativeHandle -> I haven't seen this used very much and it looks like a wrapper around a ref, which should be possible with Composition API.
• useLayoutEffect -> watchEffect and watch accept a options parameter where you can set flush to 'pre' for synchronous effects.
• useDebugValue -> I'm not sure about the status of the devtools for version 3 but for debugging in general, the watchers have debugger listeners for the options parameter (onTrack and onTrigger) and you also have a similar lifecycle hook called onRenderTracked/Triggered.

--
So to summarize: Vue hooks get called once, the state is mutable but automatically tracked, you can watch changes and component lifecycles.

The crossover between the libraries is constantly growing stronger, Vue supports render functions (and therefor JSX) like preact, so components can even be reused between libraries. You could also use Vue's reactivity model in React like described in the end of this article.

[tannerlinsley]

Nice! Thanks for making this. I actually just merged some structural changes that make the codebase easier to navigate by concern (core and react). Check it out!

[ayush987goyal]

@tannerlinsley How do you think we should structure the repo to support Vue? Considering the package nomenclature (react-query), do we still want to place the support for Vue in this repo? How would we distribute it on npm? Do you think we would need to convert this to a monorepo where we have core as it's own distribution (@react-query/core) and react/vue as consumers of core (@react-query/react and @react-query/vue)?

[tannerlinsley]

I’m not sure yet, but honestly the distribution shouldn’t matter too much at this point. We can always make it better. My gut reaction is to just add a new set of roll up exports and create a proxy file to support react-query/vue. As odd as that sounds. It makes it very easy for now.

…

On Jul 20, 2020, 9:53 PM -0600, Ayush Goyal ***@***.***>, wrote: @tannerlinsley How do you think we should structure the repo to support Vue? Considering the package nomenclature (react-query), do we still want to place the support for Vue in this repo? How would we distribute it on npm? Do you think we would need to convert this to a monorepo where we have core as it's own distribution ***@***.***/core) and react/vue as consumers of core ***@***.***/react and @react-query/core)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[tannerlinsley]

• We need to honor semver per package, so no global bumping (unless it's an actual core breaking change and all packages need to be bumped in unison)
• I don't think I can live without some type of release automation process. Don't care what it is as long as it's reliable as uses semantic-release style analysis on commit messages

I feel like technically, the best option is to make new repos like vue-query and svelte-query, which consume the react-query core. This way, we can achieve the two items above.

The only downside to this I can think of is the lack of combined effort with regards to Github stars (a flawed metric anyway). But this also makes it easier for each one to have it's own issues, discussions, and docs site.

Thoughts?

[ayush987goyal]

I agree on both the above mentioned points on separate and automate semver. Also, breaking the packages into separate repos would then make this process easy. We could create packages and npm libs like so:

react-query-core - @query/core
react-query - @query/react
vue-query - @query/vue

And yeah this will make sure they have individual discussions, issues, docs and we dont pile up issues on one repo if there are issues on one specific library package.

As far as GitHub stars and reachability is concerned, we would then have to market @query as an ecosystem (which it likely is already with @query/core) just like @testing-library.

If that is something that sounds good to you, we can start off by having react-query-core and react-query separated out right now and then work on supporting Vue/Svelte (that way we keep the current GitHub stars on react-query)

[tannerlinsley]

Hmm. There’s so much branding to consider here.... I don’t want to rush into anything. I’m about to release a course on React Query too. Hmmm

[ayush987goyal]

Yeah that would be crucial. Maybe you can consider this aspect of React Query as ecosystem and create the course and branch accordingly.

[diegopamio]

So about the semver integration, there is an ongoing issue on semantic-release around support for mon-repos. There are other packages like multi-semantic-release and semantic-release-monorepo but neither of them are full-proof.

I saw a couple of mono-repos like react-router and vue-next and both of them handle release/publish via custom scripts. As far as @testing-library is concerned, they have separate repos for each package.

Now what I can see is that we probably have three options:

1. Use the above mentioned packages that support mono-repos with semver (not used a lot).
2. Use only single version for all the packages with semver and custom script (since semver maps repo to npm package, meaning commit to any file in sub-package would also bump the version for all).
3. Separate out packages in individual repos.

Maybe there is a better way to handle this but I am not sure about that. What do you think about it?

If I’m not wrong, with Lerna you get semantic release somos for free (just a “true” in the confit and that’s it, ir even figures out which package to bump/publish). We’ve used it for our UI-library with great success.

[matepapp]

hey guys! 👋

thanks for opening this discussion, I also saw your tweet about it back then. in my company, we're elaborating to get rid of Vuex for data fetching and use other solutions to handle and cache remote data. we really like the idea of SWR and considering to adopt the Vue.js version of it, SWRV. as someone who's coming from a React background (that's me), I'm a huge fan of your work and libraries in the React ecosystem and it would be really great to use react-query in Vue.js world! after reading through your discussion I totally get that this is not like a one day job, but I would be interested what's the progress on this initiative? are you planning to support Vue 3 in a separate package (kinda dig the @query/core, @query/react, and @query/vue packages!) in the future? do you have any estimated roadmap in your mind?

[Baloche]

The Nuxt team is also working on something similar for Nuxt 3.
See the slides they published 2 hours ago introducing useFetch 😉

[diegopamio]

Any news on this? Just curious

[DamianOsipiuk]

Hey, I have started writing bindings for Vue. https://github.com/DamianOsipiuk/vue-react-query
Try it out 🎉

[mohammedzamakhan]

Why not just call it vue-query?

[DamianOsipiuk]

Yeah, initially it was. Unfortunately that name is already taken on npm 😞

[mohammedzamakhan]

@tannerlinsley the creator of react-query has taken the package name vue-query. I think you can work with him and use the name.

[DamianOsipiuk]

I did not want to just go and ask for the package name without any code.
First I would like to provide usefull functionality and get initial feedback from users, then we can think of bothering Tanner about the package name. 😉

[DamianOsipiuk]

vue-query should support most of the features of react-query as of now.
Also, it supports both Vue 2.x and 3.x, although 2.x without devtools.

[arb000r]

So now you have some code to prove itself worthy of the vue-query namesake now don't you? ;)

[DamianOsipiuk]

Good news. Thanks to @tannerlinsley
vue-query is now a thing.

[reactjser]

Good news. Thanks to @tannerlinsley
vue-query is now a thing.

Is vue-query ready for production?

[DamianOsipiuk]

I saw that already some people used it successfully in their projects.
Also not a lot of bugs were reported. So i would say that it's ready. I do not expect any breaking changes.

I still need to work on documentation, but most of the react-query docs apply with small adjustments for Vue reactivity system in regards to hooks.