@nkzw/fate-indexeddb 1.12.2 → 1.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +25 -10
  2. package/package.json +5 -5
package/README.md CHANGED
@@ -1,11 +1,8 @@
1
1
  <!-- auto-generated from docs/guide/*.md and docs/integrations/*.md. Do not edit directly. -->
2
2
 
3
3
  <p align="center">
4
- <picture>
5
- <source media="(prefers-color-scheme: dark)" srcset="/public/fate-logo-dark.svg">
6
- <source media="(prefers-color-scheme: light)" srcset="/public/fate-logo.svg">
7
- <img alt="Logo" src="/public/fate-logo.svg" width="50%">
8
- </picture>
4
+ <img alt="fate" src="/public/fate-logo.svg#gh-light-mode-only" width="50%">
5
+ <img alt="fate" src="/public/fate-logo-dark.svg#gh-dark-mode-only" width="50%">
9
6
  </p>
10
7
 
11
8
  **_fate_** is a modern data client for the web inspired by [Relay](https://relay.dev/) and [GraphQL](https://graphql.org/). It combines view composition, normalized caching, data masking, Async React features, and type-safe data fetching.
@@ -141,11 +138,8 @@ In fate, each component declares the data it needs using views. Views are compos
141
138
  Traditionally, React apps are built with components and hooks. fate introduces a third primitive: views – a declarative way for components to express their data requirements. An app built with fate looks more like this:
142
139
 
143
140
  <p align="center">
144
- <picture class="fate-tree">
145
- <source media="(prefers-color-scheme: dark)" srcset="/public/fate-tree-dark.svg">
146
- <source media="(prefers-color-scheme: light)" srcset="/public/fate-tree.svg">
147
- <img alt="Tree" src="/public/fate-tree.svg" width="90%">
148
- </picture>
141
+ <img alt="Tree" src="/public/fate-tree.svg#gh-light-mode-only" width="90%">
142
+ <img alt="Tree" src="/public/fate-tree-dark.svg#gh-dark-mode-only" width="90%">
149
143
  </p>
150
144
 
151
145
  With fate, you no longer worry about _when_ to fetch data, how to coordinate loading states, or how to handle errors imperatively. You avoid overfetching, stop passing unnecessary data down the tree, and eliminate boilerplate types created solely for passing server data to child components.
@@ -874,6 +868,8 @@ function PostComments({
874
868
 
875
869
  `useView` and `useLiveListView` can read deferred values too. This works with every transport. GraphQL currently fetches deferred fields with separate queries, rather than streaming `@defer` responses.
876
870
 
871
+ For GraphQL servers with incremental delivery enabled, [streaming batched reads](/docs/integrations/graphql.md#streaming-batched-reads) allows deferred follow-up requests to resolve independently within one HTTP response. This does not change when a deferred field is read or require different React hooks.
872
+
877
873
  ## List Views
878
874
 
879
875
  ### Pagination with `useListView`
@@ -2221,6 +2217,25 @@ Queries made together are batched into one GraphQL operation. Mutations run sepa
2221
2217
 
2222
2218
  [Deferred fields](/docs/guide/deferred-views.md) load when a component reads them. This uses ordinary GraphQL queries; incremental `@defer` responses are not supported yet.
2223
2219
 
2220
+ ### Streaming Batched Reads
2221
+
2222
+ For a server that supports GraphQL `@defer` and the `v0.2` incremental delivery protocol, enable streaming when creating your client:
2223
+
2224
+ ```tsx
2225
+ const fate = createFateClient({
2226
+ streaming: true,
2227
+ url: 'https://api.example.com/graphql',
2228
+ });
2229
+ ```
2230
+
2231
+ Reads still share one HTTP request. Each read is wrapped in its own labeled `@defer` fragment and resolves when that operation's complete result arrives. Separate requests under separate Suspense boundaries can render independently, while one request continues to wait for all the data it declares.
2232
+
2233
+ The transport negotiates `multipart/mixed;incrementalSpec=v0.2` and also accepts complete JSON responses. Mutations continue to use ordinary JSON responses. Streaming is disabled by default; enable it only after configuring your server and verifying that your proxy forwards response chunks promptly. Unsupported directives and incompatible multipart protocols produce errors rather than silently retrying requests.
2234
+
2235
+ With GraphQL Yoga, install `@graphql-yoga/plugin-defer-stream` and add `useDeferStream()` to the server's plugins. Keep client timeouts and error boundaries in place: completed reads remain available if another operation fails or the connection ends, while unfinished reads reject. Canceling one read keeps the connection alive for its siblings; the connection is released when no reads still need it.
2236
+
2237
+ This mode delivers complete operation results through the existing normalized cache. Field-level patches and item-by-item `@stream` updates are not supported. Existing fate `defer()` selections remain lazy identity-based follow-up reads, which can themselves share a streaming batch.
2238
+
2224
2239
  ### Refetch Fields
2225
2240
 
2226
2241
  For servers without `nodes(ids:)`, configure a query field for each refetchable entity type:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@nkzw/fate-indexeddb",
3
- "version": "1.12.2",
3
+ "version": "1.14.0",
4
4
  "description": "Optional IndexedDB persistence adapter for fate.",
5
5
  "license": "MIT",
6
6
  "files": [
@@ -19,10 +19,10 @@
19
19
  "idb": "^8.0.4"
20
20
  },
21
21
  "devDependencies": {
22
- "@nkzw/fate": "1.12.2",
23
- "fake-indexeddb": "^6.2.6",
24
- "vite": "npm:@voidzero-dev/vite-plus-core@1.4.0",
25
- "vite-plus": "1.4.0"
22
+ "@nkzw/fate": "1.14.0",
23
+ "fake-indexeddb": "^6.2.7",
24
+ "vite": "npm:@voidzero-dev/vite-plus-core@1.5.0",
25
+ "vite-plus": "1.5.0"
26
26
  },
27
27
  "peerDependencies": {
28
28
  "@nkzw/fate": "^1.5.1"