svelte-query VS react-svelte

Nice I was waiting for this! I'm using the old implementation: https://sveltequery.vercel.app/

I'm aware there's another Svelte Query here but it seems like it is not maintained and will be incorporated into Tanstack Query.

Until then I use Svelte Query

I like React Query so I would be excited to use this however it doesn't seem ready for Svelte given the docs "Coming Soon" and Svelte Query being relatively unmaintained.

Svelte Query :)

Or just use svelte-query and toss that observable junk to the side.

Exactly. That's the big thing I want to work on next. Not sure whether to use Svelte Query or manually cache the data. In an ideal scenario all the API calls are cached because if two users hit the site at the same time, for instance, there's no need to request the same data twice. This is getting to the edge of my skillset but psyched to try to learn this part.

That's it. Nothing highly sophisticated. It is mostly the tech I enjoy and I think is valuable in the future. There are also other libraries I really enjoy, like XState and React Query (there is also Svelte Query). Just to mention a few.

Caching: svelte-query, sswr

React’s changes over time have always been broadly compatible, and the same under the hood, just presented and manipulated a different way at the surface. Migrating to anything like Svelte would be a radical and extremely incompatible change on multiple fronts. It’s never, ever going to happen; the closest you’ll get will be another layer on top of React that embeds something like Svelte—such as https://github.com/Rich-Harris/react-svelte.

Svelte’s approach requires detailed knowledge of the structure of state, and requires compilation: components’ blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics, and some places where JavaScript is too flexible to be tractable get replaced with special template syntax (like {#each} instead of for-loops or Array.prototype.map). Svelte cannot be implemented as a JavaScript library (I disqualify eval()). Svelte is also deliberately severely limited in what it can express in various places, whereas React gives you the full power of JavaScript (for better and for worse).<p>You could perhaps implement an optimising compiler for a small subset of React components that avoid problematic patterns and are written in TypeScript with proper specifications of the types of state and props; but if you considered it unacceptable for this compiler to change the component’s semantics, I think you’d be surprised at how little serious React code in the wild could actually be supported. Even simple loops <i>might</i> be out of reach. The Svelte approach can’t be a progressive enhancement, it’s an all-or-nothing (at the component level).