Repository navigation
fix(store): log a pending patchState before a method or restore in the same tick - #277
Merged
Merged
Conversation
…e same tick Without watchState, writes outside a store method are grouped per microtask into one patchState entry, starting from a snapshot taken at the first write. A method call or a signal restore in the same tick logged its own entry without settling that snapshot first, so when the microtask ran its diff also contained the method's change. The change was logged twice, out of order, and restoring the patchState entry put back the state after the method. The pending entry is now logged before an outermost method call or a restore takes its own snapshot.
🚀 Deploying Preview to Cloudflare 🚀Preview Deployments by commit
|
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
When an app hasn't registered
watchState(the default), writes to a signal store outside a method are grouped per microtask into onepatchStateentry.onWritetakes a snapshot before the first write and queues a microtask that diffs against it.A store method (
wrapMethod) or a signal restore that runs in the same tick takes its own snapshot and logs its own entry without settling the pending one. When the microtask runs, it diffs the old snapshot against the current state, so the method's change lands in thepatchStateentry too. As a result:pangular:ngrx-store)patchStateclaiming the method's changepatchStateentry puts back the state after the method, not after the outside writeThe fix adds
flushPending, which logs the pendingpatchStateentry right away. It runs at the start of an outermost method call and before a signal restore takes its snapshot. Stores watched throughwatchStatenever have a pending entry, so they're unchanged.How it was verified
New test in
ngrx-collector.test.ts:patchStateoutside a method, then a method call in the same tick. Onmainthe log issetQuery {query}followed bypatchState {query, saved}. With the fix it'spatchState {saved}followed bysetQuery {query}. All package tests pass.pnpm commit:check(commit messages follow the guidelines)pnpm format:checkpnpm typecheck(includes thengctemplate checks)pnpm test:devtools(all passing)pnpm skills:check(when.claude/changed): not changedno-docs)pnpm extension:buildandextension/uicommitted (whenapp/changed): not changedSummary by CodeRabbit