floppy-disk 3.0.0-beta.1 → 3.0.0-beta.3
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.
- package/README.md +371 -1
- package/esm/react/create-mutation.d.mts +37 -21
- package/esm/react/create-query.d.mts +60 -57
- package/esm/react/create-store.d.mts +7 -4
- package/esm/react/create-stores.d.mts +11 -4
- package/esm/react/use-mutation.d.mts +82 -0
- package/esm/react/use-store.d.mts +18 -8
- package/esm/react.d.mts +3 -2
- package/esm/react.mjs +237 -52
- package/esm/vanilla/basic.d.mts +0 -8
- package/esm/vanilla/store.d.mts +17 -8
- package/esm/vanilla.d.mts +0 -1
- package/esm/vanilla.mjs +6 -40
- package/package.json +2 -2
- package/react/create-mutation.d.ts +37 -21
- package/react/create-query.d.ts +60 -57
- package/react/create-store.d.ts +7 -4
- package/react/create-stores.d.ts +11 -4
- package/react/use-mutation.d.ts +82 -0
- package/react/use-store.d.ts +18 -8
- package/react.d.ts +3 -2
- package/react.js +235 -50
- package/vanilla/basic.d.ts +0 -8
- package/vanilla/store.d.ts +17 -8
- package/vanilla.d.ts +0 -1
- package/vanilla.js +5 -41
- package/esm/vanilla/shallow.d.mts +0 -6
- package/vanilla/shallow.d.ts +0 -6
package/README.md
CHANGED
|
@@ -1,3 +1,373 @@
|
|
|
1
|
-
#
|
|
1
|
+
# FloppyDisk.ts 💾
|
|
2
2
|
|
|
3
3
|
A lightweight, simple, and powerful state management library.
|
|
4
|
+
|
|
5
|
+
This library was highly-inspired by [Zustand](https://www.npmjs.com/package/zustand) and [TanStack-Query](https://tanstack.com/query), they're awesome state manager.
|
|
6
|
+
FloppyDisk provides a very similar developer experience (DX), while introducing additional features and a smaller bundle size.
|
|
7
|
+
|
|
8
|
+
Comparison: https://github.com/afiiif/floppy-disk/tree/beta/comparison
|
|
9
|
+
|
|
10
|
+
**Installation:**
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
npm install floppy-disk
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Global Store
|
|
17
|
+
|
|
18
|
+
Here's how to create and use a store:
|
|
19
|
+
|
|
20
|
+
```tsx
|
|
21
|
+
import { createStore } from 'floppy-disk/react';
|
|
22
|
+
|
|
23
|
+
const useDigimon = createStore({
|
|
24
|
+
age: 3,
|
|
25
|
+
level: 'Rookie' as 'In-Training' | 'Rookie' | 'Champion' | 'Ultimate',
|
|
26
|
+
});
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
You can use the store both inside and outside of React components.
|
|
30
|
+
|
|
31
|
+
```tsx
|
|
32
|
+
function MyDigimon() {
|
|
33
|
+
const { age } = useDigimon();
|
|
34
|
+
return <div>Digimon age: {age}</div>;
|
|
35
|
+
// This component will only re-render when `age` changes.
|
|
36
|
+
// Changes to `level` will NOT trigger a re-render.
|
|
37
|
+
}
|
|
38
|
+
|
|
39
|
+
function Control() {
|
|
40
|
+
return (
|
|
41
|
+
<>
|
|
42
|
+
<button onClick={() => {
|
|
43
|
+
// You can setState directly
|
|
44
|
+
useDigimon.setState(prev => ({ age: prev.age + 1 }));
|
|
45
|
+
}}>
|
|
46
|
+
Increase digimon's age
|
|
47
|
+
</button>
|
|
48
|
+
|
|
49
|
+
<button onClick={evolve}>Evolve</button>
|
|
50
|
+
</>
|
|
51
|
+
);
|
|
52
|
+
}
|
|
53
|
+
|
|
54
|
+
// You can create a custom actions
|
|
55
|
+
const evolve = (nextLevel: 'Rookie' | 'Champion' | 'Ultimate') => {
|
|
56
|
+
const { age, level } = useDigimon.getState();
|
|
57
|
+
|
|
58
|
+
const minAge = {
|
|
59
|
+
Rookie: 3,
|
|
60
|
+
Champion: 6,
|
|
61
|
+
Ultimate: 11,
|
|
62
|
+
};
|
|
63
|
+
|
|
64
|
+
if (age < minAge[nextLevel]) {
|
|
65
|
+
return console.warn('Not enough age');
|
|
66
|
+
}
|
|
67
|
+
|
|
68
|
+
useDigimon.setState({ level: nextLevel });
|
|
69
|
+
};
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
### Differences from Zustand
|
|
73
|
+
|
|
74
|
+
If you're coming from Zustand, this should feel very familiar.\
|
|
75
|
+
Key differences:
|
|
76
|
+
|
|
77
|
+
1. **No Selectors Needed**\
|
|
78
|
+
You don't need selectors when using hooks.
|
|
79
|
+
FloppyDisk automatically tracks which parts of the state are used and optimizes re-renders accordingly.
|
|
80
|
+
2. **Object-Only Store Initialization**\
|
|
81
|
+
In FloppyDisk, stores **must** be initialized with an object. Primitive values or function initializers are not allowed.
|
|
82
|
+
|
|
83
|
+
Zustand examples:
|
|
84
|
+
|
|
85
|
+
```tsx
|
|
86
|
+
const useExample1 = create(123);
|
|
87
|
+
|
|
88
|
+
const useExample2 = create(set => ({
|
|
89
|
+
value: 1,
|
|
90
|
+
inc: () => set(prev => ({ value: prev.value + 1 })),
|
|
91
|
+
}));
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
FloppyDisk equivalents:
|
|
95
|
+
|
|
96
|
+
```tsx
|
|
97
|
+
const useExample1 = createStore({ value: 123 });
|
|
98
|
+
|
|
99
|
+
// Unlike Zustand, defining actions inside the store is **discouraged** in FloppyDisk.
|
|
100
|
+
// This improves tree-shakeability and keeps your store minimal.
|
|
101
|
+
const useExample2 = createStore({ value: 1 });
|
|
102
|
+
const inc = () => useExample2.setState(prev => ({ value: prev.value + 1 }));
|
|
103
|
+
|
|
104
|
+
// However, it's still possible if you understand how closures work:
|
|
105
|
+
const useExample2Alt = createStore({
|
|
106
|
+
value: 1,
|
|
107
|
+
inc: () => useExample2Alt.setState(prev => ({ value: prev.value + 1 })),
|
|
108
|
+
});
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
## Async State (Query & Mutation)
|
|
112
|
+
|
|
113
|
+
FloppyDisk also provides a powerful async state layer, inspired by [TanStack-Query](https://tanstack.com/query) but with a simpler API.
|
|
114
|
+
|
|
115
|
+
It is agnostic to the type of async operation,
|
|
116
|
+
it works with any Promise-based operation—whether it's a network request, local computation, storage access, or something else.
|
|
117
|
+
|
|
118
|
+
Because of that, we intentionally avoid terms like "fetch" or "refetch".\
|
|
119
|
+
Instead, we use:
|
|
120
|
+
|
|
121
|
+
- **execute** → run the async operation (same as "fetch" in TanStack-Query)
|
|
122
|
+
- **revalidate** → re-run while keeping existing data (same as "refetch" in TanStack-Query)
|
|
123
|
+
|
|
124
|
+
### Query vs Mutation
|
|
125
|
+
|
|
126
|
+
<details>
|
|
127
|
+
|
|
128
|
+
<summary>Query → Read Operations</summary>
|
|
129
|
+
|
|
130
|
+
Queries are designed for reading data.\
|
|
131
|
+
They assume:
|
|
132
|
+
|
|
133
|
+
- no side effects
|
|
134
|
+
- no data mutation
|
|
135
|
+
- safe to run multiple times
|
|
136
|
+
|
|
137
|
+
Because of this, queries come with helpful defaults:
|
|
138
|
+
|
|
139
|
+
- ✅ Retry mechanism (for transient failures)
|
|
140
|
+
- ✅ Revalidation (keep data fresh automatically)
|
|
141
|
+
- ✅ Caching & staleness control
|
|
142
|
+
|
|
143
|
+
Use queries when:
|
|
144
|
+
|
|
145
|
+
- fetching data
|
|
146
|
+
- reading from storage
|
|
147
|
+
- running idempotent async logic
|
|
148
|
+
|
|
149
|
+
</details>
|
|
150
|
+
|
|
151
|
+
<details>
|
|
152
|
+
|
|
153
|
+
<summary>Mutation → Write Operations</summary>
|
|
154
|
+
|
|
155
|
+
Mutations are designed for changing data.\
|
|
156
|
+
Examples:
|
|
157
|
+
|
|
158
|
+
- insert
|
|
159
|
+
- update
|
|
160
|
+
- delete
|
|
161
|
+
- triggering side effects
|
|
162
|
+
|
|
163
|
+
Because mutations are **not safe to repeat blindly**, FloppyDisk does **not** include:
|
|
164
|
+
|
|
165
|
+
- ❌ automatic retry
|
|
166
|
+
- ❌ automatic revalidation
|
|
167
|
+
- ❌ implicit re-execution
|
|
168
|
+
|
|
169
|
+
This is intentional.\
|
|
170
|
+
Mutations should be explicit and controlled, not automatic.
|
|
171
|
+
|
|
172
|
+
If you need retry mechanism, then you can always add it manually.
|
|
173
|
+
|
|
174
|
+
</details>
|
|
175
|
+
|
|
176
|
+
### Single Query
|
|
177
|
+
|
|
178
|
+
Create a query using `createQuery`:
|
|
179
|
+
|
|
180
|
+
```tsx
|
|
181
|
+
import { createQuery } from 'floppy-disk/react';
|
|
182
|
+
|
|
183
|
+
const myCoolQuery = createQuery(
|
|
184
|
+
myAsyncFn,
|
|
185
|
+
// { staleTime: 5000, revalidateOnFocus: false } <-- optional options
|
|
186
|
+
);
|
|
187
|
+
|
|
188
|
+
const useMyCoolQuery = myCoolQuery();
|
|
189
|
+
|
|
190
|
+
// Use it inside your component:
|
|
191
|
+
|
|
192
|
+
function MyComponent() {
|
|
193
|
+
const query = useMyCoolQuery();
|
|
194
|
+
if (query.state === 'INITIAL') return <div>Loading...</div>;
|
|
195
|
+
if (query.error) return <div>Error: {query.error.message}</div>;
|
|
196
|
+
return <div>{JSON.stringify(query.data)}</div>;
|
|
197
|
+
}
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
### Query State: Two Independent Dimensions
|
|
201
|
+
|
|
202
|
+
FloppyDisk tracks two things separately:
|
|
203
|
+
|
|
204
|
+
- Is it running? → `isPending`\
|
|
205
|
+
(value: `boolean`)
|
|
206
|
+
- What's the result? → `state`\
|
|
207
|
+
(value: `INITIAL | 'SUCCESS' | 'ERROR' | 'SUCCESS_BUT_REVALIDATION_ERROR'`)
|
|
208
|
+
|
|
209
|
+
They are **independent**.
|
|
210
|
+
|
|
211
|
+
### Automatic Re-render Optimization
|
|
212
|
+
|
|
213
|
+
Just like the global store, FloppyDisk tracks usage automatically:
|
|
214
|
+
|
|
215
|
+
```tsx
|
|
216
|
+
const { data } = useMyQuery();
|
|
217
|
+
// ^Only data changes will trigger a re-render
|
|
218
|
+
|
|
219
|
+
const value = useMyQuery().data?.foo.bar.baz;
|
|
220
|
+
// ^Only data.foo.bar.baz changes will trigger a re-render
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
### Keyed Query (Dynamic Params)
|
|
224
|
+
|
|
225
|
+
You can create parameterized queries:
|
|
226
|
+
|
|
227
|
+
```tsx
|
|
228
|
+
import { getUserById, type GetUserByIdResponse } from '../utils';
|
|
229
|
+
|
|
230
|
+
type MyQueryParam = { id: string };
|
|
231
|
+
|
|
232
|
+
const userQuery = createQuery<GetUserByIdResponse, MyQueryParam>(
|
|
233
|
+
getUserById,
|
|
234
|
+
// { staleTime: 5000, revalidateOnFocus: false } <-- optional options
|
|
235
|
+
);
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
Use it with parameters:
|
|
239
|
+
|
|
240
|
+
```tsx
|
|
241
|
+
function UserDetail({ id }) {
|
|
242
|
+
const useUserQuery = userQuery({ id: 1 });
|
|
243
|
+
const query = useUserQuery();
|
|
244
|
+
if (query.state === 'INITIAL') return <div>Loading...</div>;
|
|
245
|
+
if (query.error) return <div>Error: {query.error.message}</div>;
|
|
246
|
+
return <div>{JSON.stringify(query.data)}</div>;
|
|
247
|
+
}
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
Each unique parameter creates its own cache entry.
|
|
251
|
+
|
|
252
|
+
### Infinite Query
|
|
253
|
+
|
|
254
|
+
FloppyDisk does **not provide** a dedicated "infinite query" API.\
|
|
255
|
+
Instead, it embraces a simpler and more flexible approach:
|
|
256
|
+
|
|
257
|
+
> _Infinite queries are just **composition** + **recursion**._
|
|
258
|
+
|
|
259
|
+
Why? Because async state is already powerful enough:
|
|
260
|
+
|
|
261
|
+
- keyed queries handle parameters
|
|
262
|
+
- components handle composition
|
|
263
|
+
- recursion handles pagination
|
|
264
|
+
|
|
265
|
+
No special abstraction needed.
|
|
266
|
+
|
|
267
|
+
Here is the example on how to implement infinite query properly:
|
|
268
|
+
|
|
269
|
+
```tsx
|
|
270
|
+
type GetPostParams = {
|
|
271
|
+
cursor?: string; // For pagination
|
|
272
|
+
};
|
|
273
|
+
type GetPostsResponse = {
|
|
274
|
+
posts: Post[];
|
|
275
|
+
meta: { nextCursor: string };
|
|
276
|
+
};
|
|
277
|
+
|
|
278
|
+
const postsQuery = createQuery<GetPostsResponse, GetPostParams>(
|
|
279
|
+
getPosts,
|
|
280
|
+
{
|
|
281
|
+
staleTime: Infinity,
|
|
282
|
+
revalidateOnFocus: false,
|
|
283
|
+
revalidateOnReconnect: false,
|
|
284
|
+
},
|
|
285
|
+
);
|
|
286
|
+
|
|
287
|
+
function Main() {
|
|
288
|
+
return <Page cursor={undefined} />;
|
|
289
|
+
}
|
|
290
|
+
|
|
291
|
+
function Page({ cursor }: { cursor?: string }) {
|
|
292
|
+
const usePostsQuery = postsQuery({ cursor });
|
|
293
|
+
const { state, data, error } = usePostsQuery();
|
|
294
|
+
|
|
295
|
+
if (state === 'INITIAL') return <div>Loading...</div>;
|
|
296
|
+
if (error) return <div>Error</div>;
|
|
297
|
+
|
|
298
|
+
return (
|
|
299
|
+
<>
|
|
300
|
+
{data.posts.map(post => (
|
|
301
|
+
<PostCard key={post.id} post={post} />
|
|
302
|
+
))}
|
|
303
|
+
{data.meta.nextCursor && (
|
|
304
|
+
<LoadMore nextCursor={data.meta.nextCursor} />
|
|
305
|
+
)}
|
|
306
|
+
</>
|
|
307
|
+
);
|
|
308
|
+
}
|
|
309
|
+
|
|
310
|
+
function LoadMore({ nextCursor }: { nextCursor?: string }) {
|
|
311
|
+
const [isNextPageRequested, setIsNextPageRequested] = useState(() => {
|
|
312
|
+
const stateOfNextPageQuery = postsQuery({ cursor: nextCursor }).getState();
|
|
313
|
+
return stateOfNextPageQuery.isPending || stateOfNextPageQuery.isSuccess;
|
|
314
|
+
});
|
|
315
|
+
|
|
316
|
+
if (isNextPageRequested) {
|
|
317
|
+
return <Page cursor={nextCursor} />;
|
|
318
|
+
}
|
|
319
|
+
|
|
320
|
+
return (
|
|
321
|
+
<ReachingBottomObserver
|
|
322
|
+
onReachBottom={() => setIsNextPageRequested(true)}
|
|
323
|
+
/>
|
|
324
|
+
);
|
|
325
|
+
}
|
|
326
|
+
```
|
|
327
|
+
|
|
328
|
+
When implementing infinite queries, it is **highly recommended to disable automatic revalidation**.
|
|
329
|
+
|
|
330
|
+
Why?\
|
|
331
|
+
In an infinite list, users may scroll through many pages ("_doom-scrolling_").\
|
|
332
|
+
If revalidation is triggered:
|
|
333
|
+
|
|
334
|
+
- All previously loaded pages may re-execute
|
|
335
|
+
- Content at the top may change without the user noticing
|
|
336
|
+
- Layout shifts can occur unexpectedly
|
|
337
|
+
|
|
338
|
+
This leads to a **confusing and unstable user experience**.\
|
|
339
|
+
Revalidating dozens of previously viewed pages rarely provides value to the user.
|
|
340
|
+
|
|
341
|
+
## SSR Guidance
|
|
342
|
+
|
|
343
|
+
FloppyDisk is designed primarily for **client-side [sync/async] state**.
|
|
344
|
+
|
|
345
|
+
If your data is already fetched on the server (e.g. via SSR/ISR, Server Components, or Server Actions), then:
|
|
346
|
+
|
|
347
|
+
> **You most likely don't need this library.**
|
|
348
|
+
|
|
349
|
+
This is the same philosophy as TanStack Query. 💡
|
|
350
|
+
|
|
351
|
+
In many cases, developers mix SSR/ISR with client-side state because they want:
|
|
352
|
+
|
|
353
|
+
1. Data to be rendered into HTML on the server
|
|
354
|
+
2. The ability to **revalidate it on the client**
|
|
355
|
+
|
|
356
|
+
A common (but inefficient) approach is:
|
|
357
|
+
|
|
358
|
+
- fetch on the server
|
|
359
|
+
- hydrate it into a client-side cache
|
|
360
|
+
- then revalidate using a query library
|
|
361
|
+
|
|
362
|
+
While this works, it introduces additional complexity.
|
|
363
|
+
|
|
364
|
+
Instead, we encourage a simpler approach:
|
|
365
|
+
|
|
366
|
+
> If your data is fetched on the server, revalidate it using **your framework's built-in mechanism** (e.g. Next.js route revalidation).
|
|
367
|
+
|
|
368
|
+
Because of this philosophy, FloppyDisk **does not support** hydrating server-fetched data into the client store.
|
|
369
|
+
|
|
370
|
+
This keeps the mental model clean:
|
|
371
|
+
|
|
372
|
+
- server data → handled by the framework
|
|
373
|
+
- client async state → handled by FloppyDisk
|
|
@@ -14,7 +14,7 @@ import { type InitStoreOptions, type SetState } from 'floppy-disk/vanilla';
|
|
|
14
14
|
* - No retry mechanism
|
|
15
15
|
* - No caching across executions
|
|
16
16
|
*/
|
|
17
|
-
export type MutationState<TData, TVariable> = {
|
|
17
|
+
export type MutationState<TData, TVariable, TError> = {
|
|
18
18
|
isPending: boolean;
|
|
19
19
|
} & ({
|
|
20
20
|
state: 'INITIAL';
|
|
@@ -41,28 +41,42 @@ export type MutationState<TData, TVariable> = {
|
|
|
41
41
|
variable: TVariable;
|
|
42
42
|
data: undefined;
|
|
43
43
|
dataUpdatedAt: undefined;
|
|
44
|
-
error:
|
|
44
|
+
error: TError;
|
|
45
45
|
errorUpdatedAt: number;
|
|
46
46
|
});
|
|
47
|
+
export declare const INITIAL_STATE: {
|
|
48
|
+
state: string;
|
|
49
|
+
isPending: boolean;
|
|
50
|
+
isSuccess: boolean;
|
|
51
|
+
isError: boolean;
|
|
52
|
+
variable: undefined;
|
|
53
|
+
data: undefined;
|
|
54
|
+
dataUpdatedAt: undefined;
|
|
55
|
+
error: undefined;
|
|
56
|
+
errorUpdatedAt: undefined;
|
|
57
|
+
};
|
|
47
58
|
/**
|
|
48
59
|
* Configuration options for a mutation.
|
|
49
60
|
*
|
|
50
61
|
* @remarks
|
|
51
62
|
* Lifecycle callbacks are triggered for each execution.
|
|
52
63
|
*/
|
|
53
|
-
export type MutationOptions<TData, TVariable> = InitStoreOptions<MutationState<TData, TVariable>> & {
|
|
64
|
+
export type MutationOptions<TData, TVariable, TError = Error> = InitStoreOptions<MutationState<TData, TVariable, TError>> & {
|
|
54
65
|
/**
|
|
55
|
-
* Called when the mutation succeeds
|
|
66
|
+
* Called when the mutation succeeds.\
|
|
67
|
+
* If multiple concurrent executions happened, only the latest execution triggers this callback.
|
|
56
68
|
*/
|
|
57
|
-
onSuccess?: (data: TData, variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable>) => void;
|
|
69
|
+
onSuccess?: (data: TData, variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable, TError>) => void;
|
|
58
70
|
/**
|
|
59
|
-
* Called when the mutation fails
|
|
71
|
+
* Called when the mutation fails.\
|
|
72
|
+
* If multiple concurrent executions happened, only the latest execution triggers this callback.
|
|
60
73
|
*/
|
|
61
|
-
onError?: (error:
|
|
74
|
+
onError?: (error: TError, variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable, TError>) => void;
|
|
62
75
|
/**
|
|
63
|
-
* Called after the mutation settles (either success or error)
|
|
76
|
+
* Called after the mutation settles (either success or error).\
|
|
77
|
+
* If multiple concurrent executions happened, only the latest execution triggers this callback.
|
|
64
78
|
*/
|
|
65
|
-
onSettled?: (variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable>) => void;
|
|
79
|
+
onSettled?: (variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable, TError>) => void;
|
|
66
80
|
};
|
|
67
81
|
/**
|
|
68
82
|
* Creates a mutation store for handling async operations that modify data.
|
|
@@ -78,8 +92,10 @@ export type MutationOptions<TData, TVariable> = InitStoreOptions<MutationState<T
|
|
|
78
92
|
* - Mutations are **not cached** and only track the latest execution.
|
|
79
93
|
* - Designed for operations that change data (e.g. create, update, delete).
|
|
80
94
|
* - No retry mechanism is provided by default.
|
|
81
|
-
* - Each execution overwrites the previous state.
|
|
82
95
|
* - The mutation always resolves (never throws): the result contains either `data` or `error`.
|
|
96
|
+
* - If multiple executions triggered at the same time:
|
|
97
|
+
* - Only the latest execution is allowed to update the state.
|
|
98
|
+
* - Results from previous executions are ignored if a newer one exists.
|
|
83
99
|
*
|
|
84
100
|
* @example
|
|
85
101
|
* const useCreateUser = createMutation(async (input) => {
|
|
@@ -89,10 +105,10 @@ export type MutationOptions<TData, TVariable> = InitStoreOptions<MutationState<T
|
|
|
89
105
|
* const { isPending } = useCreateUser();
|
|
90
106
|
* const result = await useCreateUser.execute({ name: 'John' });
|
|
91
107
|
*/
|
|
92
|
-
export declare const createMutation: <TData, TVariable = undefined>(mutationFn: (variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable>) => Promise<TData>, options?: MutationOptions<TData, TVariable>) => (
|
|
93
|
-
subscribe: (subscriber: import("../vanilla.d.mts").Subscriber<MutationState<TData, TVariable>>) => () => void;
|
|
94
|
-
getSubscribers: () => Set<import("../vanilla.d.mts").Subscriber<MutationState<TData, TVariable>>>;
|
|
95
|
-
getState: () => MutationState<TData, TVariable>;
|
|
108
|
+
export declare const createMutation: <TData, TVariable = undefined, TError = Error>(mutationFn: (variable: TVariable, stateBeforeExecute: MutationState<TData, TVariable, TError>) => Promise<TData>, options?: MutationOptions<TData, TVariable, TError>) => (() => MutationState<TData, TVariable, TError>) & {
|
|
109
|
+
subscribe: (subscriber: import("../vanilla.d.mts").Subscriber<MutationState<TData, TVariable, TError>>) => () => void;
|
|
110
|
+
getSubscribers: () => Set<import("../vanilla.d.mts").Subscriber<MutationState<TData, TVariable, TError>>>;
|
|
111
|
+
getState: () => MutationState<TData, TVariable, TError>;
|
|
96
112
|
/**
|
|
97
113
|
* Manually updates the mutation state.
|
|
98
114
|
*
|
|
@@ -100,7 +116,7 @@ export declare const createMutation: <TData, TVariable = undefined>(mutationFn:
|
|
|
100
116
|
* - Intended for advanced use cases.
|
|
101
117
|
* - Prefer using provided mutation actions (`execute`, `reset`) instead.
|
|
102
118
|
*/
|
|
103
|
-
setState: (value: SetState<MutationState<TData, TVariable>>) => void;
|
|
119
|
+
setState: (value: SetState<MutationState<TData, TVariable, TError>>) => void;
|
|
104
120
|
/**
|
|
105
121
|
* Executes the mutation.
|
|
106
122
|
*
|
|
@@ -111,25 +127,25 @@ export declare const createMutation: <TData, TVariable = undefined>(mutationFn:
|
|
|
111
127
|
* - `{ error, variable }` on failure
|
|
112
128
|
*
|
|
113
129
|
* @remarks
|
|
114
|
-
* - If a mutation is already in progress, a warning is logged.
|
|
115
|
-
* - Concurrent executions are allowed but may lead to race conditions.
|
|
116
130
|
* - The promise never rejects to simplify async handling.
|
|
131
|
+
* - If a mutation is already in progress, a warning is logged.
|
|
132
|
+
* - When a new execution starts, all previous pending executions will resolve with the result of the latest execution.
|
|
117
133
|
*/
|
|
118
134
|
execute: TVariable extends undefined ? () => Promise<{
|
|
119
135
|
variable: undefined;
|
|
120
136
|
data?: TData;
|
|
121
|
-
error?:
|
|
137
|
+
error?: TError;
|
|
122
138
|
}> : (variable: TVariable) => Promise<{
|
|
123
139
|
variable: TVariable;
|
|
124
140
|
data?: TData;
|
|
125
|
-
error?:
|
|
141
|
+
error?: TError;
|
|
126
142
|
}>;
|
|
127
143
|
/**
|
|
128
144
|
* Resets the mutation state back to its initial state.
|
|
129
145
|
*
|
|
130
146
|
* @remarks
|
|
131
|
-
* - Does not cancel any ongoing
|
|
132
|
-
* - If
|
|
147
|
+
* - Does not cancel any ongoing execution.
|
|
148
|
+
* - If an execution is still pending, its result may override the reset state.
|
|
133
149
|
*/
|
|
134
150
|
reset: () => void;
|
|
135
151
|
};
|