Conversation
👷 Deploy request for tanstack pending review.Visit the deploys page to approve it
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip You can customize the tone of the review comments and chat replies.Configure the |
|
|
||
| TanStack DB 0.6 is the release that lands some highly anticipated features that many of you have been asking for, making it a lot more ergonomic for app development. | ||
|
|
||
| You can now project normalized data into the same hierarchical structure as your UI. You can optionally persist local state with a SQLite-backed persistence layer across runtimes. You can trigger reactive side effects from live queries. You can build outbox views and WhatsApp-style delivery indicators directly from row metadata. And a few APIs that used to rely on implicit magic are now getting more explicit and uniform. |
There was a problem hiding this comment.
"WhatsApp-style delivery indicators" perhaps "WhatsApp-like delivery indicators" is more natural?
There was a problem hiding this comment.
"And a few APIs that used to rely on implicit magic are now getting more explicit and uniform."
|
|
||
| Here is what shipped: | ||
|
|
||
| - [Persisted local state](#persisted-local-state) with an optional SQLite-backed persistence layer across browser, React Native, Expo, Node, Electron, Capacitor, Tauri, and Cloudflare Durable Objects |
There was a problem hiding this comment.
Should it be "Persisted" or "Persistent"?
I'm not a native speaker but i believe that "persisted" would be used when we mean to say that we persisted some local state. Whereas "persistent" is the more general concept that we support "persistent local state". If you agree then we need to also change that in that section's heading.
There was a problem hiding this comment.
It does read a bit repetitive though
"Persistent local state with an optional SQLite-backed persistence layer"
Seems like we're saying the same thing twice. Perhaps this reads better:
"Persistent local state thanks to/through an optional SQLite-backed persistence layer"
| Here is what shipped: | ||
|
|
||
| - [Persisted local state](#persisted-local-state) with an optional SQLite-backed persistence layer across browser, React Native, Expo, Node, Electron, Capacitor, Tauri, and Cloudflare Durable Objects | ||
| - [Includes](#includes-project-your-data-into-the-same-shape-as-your-ui) for projecting normalized data into the same hierarchical structure as your UI. Similar to GraphQL, but without the need for new infrastructure. |
There was a problem hiding this comment.
into the same hierarchical structure as your UI.
i'd simplify:
into the hierarchical structure of your UI.
|
|
||
| > Demo video embed coming soon. | ||
|
|
||
| It starts up from persisted SQLite state through `op-sqlite`, projects normalized data into a hierarchical UI shape with [includes](#includes-project-your-data-into-the-same-shape-as-your-ui), and still keeps TanStack DB's fine-grained reactivity underneath. But the really important thing is what that persistence unlocks when you pair it with [`@tanstack/offline-transactions`](https://github.com/TanStack/db/tree/main/packages/offline-transactions). |
There was a problem hiding this comment.
Can probably remove "up" in "It start up from persisted SQLite state"
|
|
||
| ### More than local-first | ||
|
|
||
| Persistence is the feature people asked for, but it does not define TanStack DB. The core idea is simpler: put a real query engine and transaction engine on the client, and let storage and synchronization live wherever they belong. Local-first is one configuration of that. Server-authoritative with fast optimistic updates is another. The same primitives support both. |
There was a problem hiding this comment.
What about "put a real transactional query engine on the client" ?
There was a problem hiding this comment.
The same primitives support both.
I would flip it around, given that we just gave the 2 examples:
Both are supported by the same primitives.
| await effect.dispose() | ||
| ``` | ||
|
|
||
| Combined with [persisted local state](#persisted-local-state) in something like a Cloudflare Durable Object, TanStack DB starts to look like a durable state engine for agent workflows, not just a UI data layer. This is only one example, but it shows why the 0.6 features matter together: [includes](#includes-project-your-data-into-the-same-shape-as-your-ui), [virtual props](#virtual-props-outboxes-delivery-state-and-row-provenance), and reactive effects all compose into something much more powerful than any one feature on its own. |
| - `$key`: the row key for the result | ||
| - `$collectionId`: the source collection ID | ||
|
|
||
| That gives you access to state that used to be awkward or bolted on. |
There was a problem hiding this comment.
What does it mean for "state to be awkward".
I think you mean "to state that used to be hidden"
|
|
||
| You can use them for workflow automation together with `createEffect`, but they are also immediately useful for UI: | ||
|
|
||
| - an outbox view of un-persisted data |
There was a problem hiding this comment.
un-persisted is correct but unpersisted is more common
| - tests | ||
| - AI and LLM context building | ||
|
|
||
| It is a small feature, but it rounds out the API in an important way. You can now use the same query language for both reactive and one-off reads. |
|
|
||
| TanStack DB is different from TanStack Query and from a classic API-driven application architecture. The SSR story is not just "do what Query does, but for DB". DB has a different execution model, a different relationship between local and remote state, and a different set of tradeoffs around hydration, persistence, and live updates. | ||
|
|
||
| So rather than rushing into a shallow solution, we want design partners. We are actively exploring the shape of SSR support for TanStack DB, and we want to hear from teams who are interested in using it seriously. |
There was a problem hiding this comment.
"we want design partners" -> "we want to think this through with design partners" ?
This is a blog post for v0.6 of DB, it is brining a bunch of new exciting stuff.
To do:
Form is here: #776