@tanstack/[email protected]

Patch Changes

• Expose utilities on collection instances (#161)

  Implemented a utility exposure pattern for TanStack DB collections that allows utility functions to be passed as part of collection options and exposes them under a .utils namespace, with full TypeScript typing.

  • Refactored createCollection in packages/db/src/collection.ts to accept options with utilities directly
  • Added utils property to CollectionImpl
  • Added TypeScript types for utility functions and utility records
  • Changed Collection from a class to a type, updating all usages to use createCollection() instead
  • Updated Electric/Query implementations
  • Utilities are now ergonomically accessible under .utils
  • Full TypeScript typing is preserved for both collection data and utilities
  • API is clean and straightforward - users can call createCollection(optionsCreator(config)) directly
  • Zero-boilerplate TypeScript pattern that infers utility types automatically

• Updated dependencies [8b43ad3]:

  • @tanstack/[email protected]

@tanstack/[email protected]

Patch Changes

• Updated dependencies [856be72, 0455e27, 80fdac7]:
  • @tanstack/[email protected]

@tanstack/[email protected]

Patch Changes

• Expose utilities on collection instances (#161)

  Implemented a utility exposure pattern for TanStack DB collections that allows utility functions to be passed as part of collection options and exposes them under a .utils namespace, with full TypeScript typing.

  • Refactored createCollection in packages/db/src/collection.ts to accept options with utilities directly
  • Added utils property to CollectionImpl
  • Added TypeScript types for utility functions and utility records
  • Changed Collection from a class to a type, updating all usages to use createCollection() instead
  • Updated Electric/Query implementations
  • Utilities are now ergonomically accessible under .utils
  • Full TypeScript typing is preserved for both collection data and utilities
  • API is clean and straightforward - users can call createCollection(optionsCreator(config)) directly
  • Zero-boilerplate TypeScript pattern that infers utility types automatically

@tanstack/[email protected]

Patch Changes

• live query where clauses can now be a callback function that receives each row as a context object allowing full javascript access to the row data for filtering (#152)

• the live query select clause can now be a callback function that receives each row as a context object returning a new object with the selected fields. This also allows the for the callback to make more expressive changes to the returned data. (#154)

• This change introduces a more streamlined and intuitive API for handling mutations by allowing onInsert, onUpdate, and onDelete handlers to be defined directly on the collection configuration. (#156)

  When collection.insert(), .update(), or .delete() are called outside of an explicit transaction (i.e., not within useOptimisticMutation), the library now automatically creates a single-operation transaction and invokes the corresponding handler to persist the change.

  Key changes:

  • @tanstack/db: The Collection class now supports onInsert, onUpdate, and onDelete in its configuration. Direct calls to mutation methods will throw an error if the corresponding handler is not defined.
  • @tanstack/db-collections:
    • queryCollectionOptions now accepts the new handlers and will automatically refetch the collection's query after a handler successfully completes. This behavior can be disabled if the handler returns { refetch: false }.
    • electricCollectionOptions also accepts the new handlers. These handlers are now required to return an object with a transaction ID ({ txid: string }). The collection then automatically waits for this txid to be synced back before resolving the mutation, ensuring consistency.
  • Breaking Change: Calling collection.insert(), .update(), or .delete() without being inside a useOptimisticMutation callback and without a corresponding persistence handler (onInsert, etc.) configured on the collection will now throw an error.

  This new pattern simplifies the most common use cases, making the code more declarative. The useOptimisticMutation hook remains available for more complex scenarios, such as transactions involving multiple mutations across different collections.

  ---

  The documentation and the React Todo example application have been significantly refactored to adopt the new direct persistence handler pattern as the primary way to perform mutations.

  • The README.md and docs/overview.md files have been updated to de-emphasize useOptimisticMutation for simple writes. They now showcase the much simpler API of calling collection.insert() directly and defining persistence logic in the collection's configuration.
  • The React Todo example (examples/react/todo/src/App.tsx) has been completely overhauled. All instances of useOptimisticMutation have been removed and replaced with the new onInsert, onUpdate, and onDelete handlers, resulting in cleaner and more concise code.

@tanstack/[email protected]

Patch Changes

• Expose utilities on collection instances (#161)

  Implemented a utility exposure pattern for TanStack DB collections that allows utility functions to be passed as part of collection options and exposes them under a .utils namespace, with full TypeScript typing.

  • Refactored createCollection in packages/db/src/collection.ts to accept options with utilities directly
  • Added utils property to CollectionImpl
  • Added TypeScript types for utility functions and utility records
  • Changed Collection from a class to a type, updating all usages to use createCollection() instead
  • Updated Electric/Query implementations
  • Utilities are now ergonomically accessible under .utils
  • Full TypeScript typing is preserved for both collection data and utilities
  • API is clean and straightforward - users can call createCollection(optionsCreator(config)) directly
  • Zero-boilerplate TypeScript pattern that infers utility types automatically

• Updated dependencies [8b43ad3]:

  • @tanstack/[email protected]

@tanstack/[email protected]

Patch Changes

• This change introduces a more streamlined and intuitive API for handling mutations by allowing onInsert, onUpdate, and onDelete handlers to be defined directly on the collection configuration. (#156)

  When collection.insert(), .update(), or .delete() are called outside of an explicit transaction (i.e., not within useOptimisticMutation), the library now automatically creates a single-operation transaction and invokes the corresponding handler to persist the change.

  Key changes:

  • @tanstack/db: The Collection class now supports onInsert, onUpdate, and onDelete in its configuration. Direct calls to mutation methods will throw an error if the corresponding handler is not defined.
  • @tanstack/db-collections:
    • queryCollectionOptions now accepts the new handlers and will automatically refetch the collection's query after a handler successfully completes. This behavior can be disabled if the handler returns { refetch: false }.
    • electricCollectionOptions also accepts the new handlers. These handlers are now required to return an object with a transaction ID ({ txid: string }). The collection then automatically waits for this txid to be synced back before resolving the mutation, ensuring consistency.
  • Breaking Change: Calling collection.insert(), .update(), or .delete() without being inside a useOptimisticMutation callback and without a corresponding persistence handler (onInsert, etc.) configured on the collection will now throw an error.

  This new pattern simplifies the most common use cases, making the code more declarative. The useOptimisticMutation hook remains available for more complex scenarios, such as transactions involving multiple mutations across different collections.

  ---

  The documentation and the React Todo example application have been significantly refactored to adopt the new direct persistence handler pattern as the primary way to perform mutations.

  • The README.md and docs/overview.md files have been updated to de-emphasize useOptimisticMutation for simple writes. They now showcase the much simpler API of calling collection.insert() directly and defining persistence logic in the collection's configuration.
  • The React Todo example (examples/react/todo/src/App.tsx) has been completely overhauled. All instances of useOptimisticMutation have been removed and replaced with the new onInsert, onUpdate, and onDelete handlers, resulting in cleaner and more concise code.

• Updated dependencies [856be72, 0455e27, 80fdac7]:

  • @tanstack/[email protected]

@tanstack/[email protected]

Patch Changes

• Collections must have a getId function & use an id for update/delete operators (#134)

• the keyBy query operator has been removed, keying withing the query pipeline is now automatic (#144)

• Updated dependencies [1fbb844, 338efc2, ee5d026, e7b036c, e4feb0c]:

  • @tanstack/[email protected]

@tanstack/[email protected]

Patch Changes

• Collections must have a getId function & use an id for update/delete operators (#134)

• the keyBy query operator has been removed, keying withing the query pipeline is now automatic (#144)

• Updated dependencies [1fbb844, 338efc2, ee5d026, e7b036c, e4feb0c]:

  • @tanstack/[email protected]

@tanstack/[email protected]

Patch Changes

• Collections must have a getId function & use an id for update/delete operators (#134)

• the select operator is not optional on a query, it will default to returning the whole row for a basic query, and a namespaced object when there are joins (#148)

• the keyBy query operator has been removed, keying withing the query pipeline is now automatic (#144)

• update d2ts to to latest version that improves hashing performance (#136)

• Switch to Collection options factories instead of extending the Collection class (#145)

  This refactors ElectricCollection and QueryCollection into factory functions (electricCollectionOptions and queryCollectionOptions) that return standard CollectionConfig objects and utility functions. Also adds a createCollection function to standardize collection instantiation.

@tanstack/[email protected]

Patch Changes

• Collections must have a getId function & use an id for update/delete operators (#134)

• Switch to Collection options factories instead of extending the Collection class (#145)

  This refactors ElectricCollection and QueryCollection into factory functions (electricCollectionOptions and queryCollectionOptions) that return standard CollectionConfig objects and utility functions. Also adds a createCollection function to standardize collection instantiation.

• Updated dependencies [1fbb844, 338efc2, ee5d026, e7b036c, e4feb0c]:

  • @tanstack/[email protected]