React-query clone doesn't exist - not applicable or not enough demand?

[kanishka]

React query claims that it addresses:

Caching... (possibly the hardest thing to do in programming)
Deduping multiple requests for the same data into a single request
Updating "out of date" data in the background
Knowing when data is "out of date"
Reflecting updates to data as quickly as possible
Performance optimizations like pagination and lazy loading data
Managing memory and garbage collection of server state
Memoizing query results with structural sharing

Is there no elm competitor or predecessor because such an abstraction would not be a good fit within an elm application, because not enough elm developers have expressed interest in such a generic library or most are happy with their current implementation handling, or some other reason I am unaware of? Is there an existing collection of smaller elm libraries that provide these features that I am unaware of?

disclaimer: I have read about react-query in passing a few times. I haven’t used it.

[gampleman]

(My familiarity with react-query specifically is very low, so this may be an entirely misguided opinion. Heap on salt as you see fit.)

My perception is that this comes down largely to differences in architecture between TEA and a typical React application. React applications are component oriented, and so the idea is that each component can independently declare its data requirements. If you just do that in a

useEffect(() => {
    fetch(`some-url?some-param=${someInput}`)
        .then(r => r.json()).then(setState);
});

or some such, you will end up with loads of requests, since you can instantiate a component as many times as you wish and components might re-render for various reasons, so its difficult to not massively over-fetch data doing it like that (it’s possible, but requires care).

Hence there is need for a layer that gives you a nice API to request data from the component level, but solves this problem of overfetching and potentially also batching requests (at least similar graphql libraries do that AFAIK).

A typical Elm app works completely differently. Effect handling is typically fairly centralised by design and since we don’t have a component oriented architecture, we don’t really have this problem typically to begin with. If you have the entire state of your application in one place at hand, it’s usually fairly straightforward to figure out if and when you need to fetch more or additional data. In-memory caching isn’t too much harder in that situation.

I hope that answers why we don’t have something like react-query.

---

On the non-in-memory caching story, I think it’s mostly a lack of access of the relevant APIs. Nobody can really make a package that abstracts over things like localStorage, IndexedDB or service worker, so doing more sophisticated caching isn’t much of an option for an Elm package. It’s possible that something like elm-pages or elm-land could come up with an abstraction for that. Not sure if they have it or have looked into it…

[wolfadex]

The store pattern might be close in some regards https://youtu.be/BCmNX2Tx5xY?si=2Fg8PTGfjQ_5L2wA mostly around the caching side.