-
Notifications
You must be signed in to change notification settings - Fork 100
Add acceptMutations utility for local collections in manual transactions #638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Fixes #446 Local-only and local-storage collections now expose `utils.acceptMutations(transaction, collection)` that must be called in manual transaction `mutationFn` to persist mutations. This provides explicit control over when local mutations are persisted, following the pattern established by query-db-collection. Changes: - Add acceptMutations to LocalOnlyCollectionUtils interface - Add acceptMutations to LocalStorageCollectionUtils interface - Include JSON serialization validation in local-storage acceptMutations - Update documentation with manual transaction usage examples 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
🦋 Changeset detectedLatest commit: dbfe4c8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Replace `unknown` with `Record<string, unknown>` in PendingMutation type parameters and related generics to satisfy the `T extends object` constraint. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
More templates
@tanstack/angular-db
@tanstack/db
@tanstack/db-ivm
@tanstack/electric-db-collection
@tanstack/query-db-collection
@tanstack/react-db
@tanstack/rxdb-db-collection
@tanstack/solid-db
@tanstack/svelte-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
Size Change: +242 B (+0.32%) Total Size: 75.4 kB
ℹ️ View Unchanged
|
Size Change: 0 B Total Size: 1.47 kB ℹ️ View Unchanged
|
…-manual-transactions
Add LocalOnlyCollectionUtils type parameter to createCollection call to satisfy type constraints after merge. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conceptional I think this is good, however if this is becoming a generic pattern it shouldn't be on the utils
namespace, but on the top level.
Could we just have a collection.acceptMutations(transaction)
method that forwards to the relevant onInsert/Update/Delete
method when available?
That would work with all collections then.
*/ | ||
acceptMutations: ( | ||
transaction: { mutations: Array<PendingMutation<Record<string, unknown>>> }, | ||
collection: unknown |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why you have to pass the collection in here, that seems unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm I thought I'd gotten rid of all of those. Will remove
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There really should be tests for this new functionality
It's not — this is only intended for collections with no backend. It'd be very odd to do this e.g. for the query/electric collections as then nothing would be written to the backend. |
But any collection with if you try and use it on a collection that does not have the appropriate |
Ok, I see where you're going — letting people rely on their onInsert/onUpdate/onDelete logic even for actions/custom transactions — I'm not a fan of that tbh — the great thing about collection handlers is the logic is very focused/simple as you know it's just coming from collection mutators. So keeping a clean separation between collection direct state changes & everything else is worthwhile. People commonly use api clients & helpers to abstract out any shared logic. |
Summary
utils.acceptMutations(transaction, collection)
to local-only and local-storage collectionsContext
Manual transactions with local-only and local-storage collections were losing changes because these collections rely on their mutation handlers (
onInsert
/onUpdate
/onDelete
) being called to persist data. When operations occur insidetx.mutate()
, handlers aren't automatically called - only the outer transaction'smutationFn
runs.Solution
Following the pattern from
@tanstack/query-db-collection
, both collection types now expose autils.acceptMutations(transaction, collection)
method that users explicitly call in their transaction'smutationFn
to persist local mutations:Changes
acceptMutations
toLocalOnlyCollectionUtils
interfaceacceptMutations
toLocalStorageCollectionUtils
interfaceTest plan
🤖 Generated with Claude Code