fix: normalize keys before join operation

[hugiex]

Description

To fix the issue #934

Problem

• join conditions like eq(left.date, right.date) were using raw Date object as join keys
• the join index uses Map key identify => the diff Date instance with the same timestamp did not match

Solution

• normalize join keys (Date -> timestamp)
• also tests created to cover the initial matching and live updates when timestamps changes

[changeset-bot]

🦋 Changeset detected

Latest commit: 5bcb579

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 12 packages

Name	Type
@tanstack/db	Patch
@tanstack/angular-db	Patch
@tanstack/electric-db-collection	Patch
@tanstack/offline-transactions	Patch
@tanstack/powersync-db-collection	Patch
@tanstack/query-db-collection	Patch
@tanstack/react-db	Patch
@tanstack/rxdb-db-collection	Patch
@tanstack/solid-db	Patch
@tanstack/svelte-db	Patch
@tanstack/trailbase-db-collection	Patch
@tanstack/vue-db	Patch

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

[pkg-pr-new]

More templates

• tanstack-start-example-basic
• @tanstack/db-example-paced-mutations-demo
• tanstack-start-db-projects-example
• @tanstack/db-example-react-todo
• todos
• offline-transactions-react-native
• @tanstack/db-example-solid-todo

@tanstack/angular-db

npm i https://pkg.pr.new/@tanstack/angular-db@1229

@tanstack/db

npm i https://pkg.pr.new/@tanstack/db@1229

@tanstack/db-ivm

npm i https://pkg.pr.new/@tanstack/db-ivm@1229

@tanstack/electric-db-collection

npm i https://pkg.pr.new/@tanstack/electric-db-collection@1229

@tanstack/offline-transactions

npm i https://pkg.pr.new/@tanstack/offline-transactions@1229

@tanstack/powersync-db-collection

npm i https://pkg.pr.new/@tanstack/powersync-db-collection@1229

@tanstack/query-db-collection

npm i https://pkg.pr.new/@tanstack/query-db-collection@1229

@tanstack/react-db

npm i https://pkg.pr.new/@tanstack/react-db@1229

@tanstack/rxdb-db-collection

npm i https://pkg.pr.new/@tanstack/rxdb-db-collection@1229

@tanstack/solid-db

npm i https://pkg.pr.new/@tanstack/solid-db@1229

@tanstack/svelte-db

npm i https://pkg.pr.new/@tanstack/svelte-db@1229

@tanstack/trailbase-db-collection

npm i https://pkg.pr.new/@tanstack/trailbase-db-collection@1229

@tanstack/vue-db

npm i https://pkg.pr.new/@tanstack/vue-db@1229

commit: 3a23b30

[kevin-dp]

Thanks for the fix! I pushed an additional commit to also normalize the value in the in evaluator (evaluators.ts).

Why this is needed: The join compiler has a lazy-loading optimization where the active side's join keys are passed into inArray(ref, joinKeys) to selectively load matching rows from the lazy side (instead of loading the entire collection). After your fix, those joinKeys are normalized (e.g. Date → timestamp number), but the in evaluator was comparing them against the raw field values using Array.includes() (strict equality). So [1234567890].includes(new Date(1234567890)) would return false, causing the optimization to silently fall back to loading the full collection.

The fix normalizes the value in the in evaluator, consistent with how eq already normalizes both operands.

[kevin-dp]

While reviewing, I found an additional related bug: inArray in WHERE clauses also doesn't work with Date objects. Reproduced in this test: https://github.com/TanStack/db/actions/runs/21949227368/job/63395185329

For example, .where(({ item }) => inArray(item.createdAt, [new Date('2025-01-01')])) returns no results because the in evaluator uses Array.includes() which relies on strict reference equality (===), so different Date instances with the same timestamp never match.

This is the same class of bug as the original join issue — just in a different code path. The fix (commit 3a23b30) normalizes both the value and the array elements in the in evaluator:

// Before
return array.includes(value)

// After
return array.some((item) => normalizeValue(item) === value)

This makes in consistent with eq, which already normalizes both operands. A test was added in the previous commit (f57873c) to cover this case.

[samwillis]

[github-actions]

🎉 This PR has been released!

• @tanstack/db@0.5.26

Thank you for your contribution!