General Async(Value|Result) + transformations for gluing across products

[ignatz]

Hi,

I hope the answer to my question/suggestion is just: "read the manual" :). I'm trying to plug various products such as TanStack query, forms, tables, ... . Specifically, I have a table component where I would like to show skeleton rows until loading finishes or error otherwise.

The closest to what I have in mind is something like QueryObserverResult, however it's pretty tedious to construct from sources other than query or to transform. Was wondering if you have maybe an external recommendation, have thought about something like this before, or even if "TanStack Glue" is something you've considered?

To be clear, what I'm asking for is already possible, it's more a question about convenience and separation (e.g. doing the same with TS tables but a different data fetching library).

Thanks and keep up the great work

[officialTechBro]

A generic “AsyncValue” abstraction makes sense conceptually, but TanStack likely avoids a shared type on purpose. Each product (Query, Tables, Forms) has different semantics (pending vs fetching, placeholder data, retries, partial errors, etc.), and unifying them either loses nuance or recreates each domain model.

In practice, the common pattern is to normalize at the app boundary into a small UI-focused shape (e.g. loading | error | success) instead of trying to construct or transform QueryObserverResult outside Query. That keeps tables/forms decoupled from the data source while still supporting skeletons and error states.

So while “TanStack Glue” would be convenient, most apps end up with a tiny Async* union + adapters per source, which keeps separation without over-coupling.

[ignatz]

FWIW, I'm not saying TS tables should have a notion of loading but rather that QueryObserverResult feels a bit too unwieldy for me to plug directly into tables.

most apps end up with a tiny Async* union + adapters per source, which keeps separation without over-coupling.

With me doing the plugging, I don't see the difference in coupling only because I keep re-inventing the same abstractions for every project. I would take your point more as: "yes, there is a need" :)