ta
TanStack
OSS
ta
Pipelines
Nx runs
Insights
Compare tasks
Analytics
Sign in
Toggle Sidebar
vi
virtual
Pipelines
fix(virtual-core): keep an instant scroll command through a transient clamp (#1329) * fix(virtual-core): keep an instant scroll command through a transient clamp Rows measured before an instant scrollToEnd() reports back can shrink the sizer below the written position and then grow it again in the same task. The browser clamps the write to the smaller max, and the scroll event reports that position: neither the write target nor the current max, so it was classified as external and the command was retired short of the end. resizeItem now follows the scroll max while a command's instant write is unreported (element max read once, then each delta, no measurement rebuild), and classifyScrollEvent reads an event between the lowest max and the target as clampedReadBack, so reconcile retargets to the end. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(virtual-core): count a pre-shrunk max and rewrite after a transient clamp Review follow-ups for the transient-clamp read-back: - The element max read at the first resize after the write counts toward `lowestMax`: the sizer can already be below the target when that resize arrives. - After such a clamp, an index or end command moves `lastTargetOffset` to the clamped position, so reconcile writes the target again even when the layout came back to the same end. Only for a clamp below the element's current max; the clamp at the current max (#1310) is unchanged. - The max is followed only while `_awaitingCommandReadBack()` holds (not under an iOS dragging finger) and only with one lane, where a row's delta is the total's. Scroll-trace snapshots are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(virtual-core): match a transient clamp to a max the layout took A clamped read-back below the element's current max was accepted anywhere between the lowest tracked max and the target, so a user scroll that landed in that range before the read-back kept the command. The browser clamps to a max the sizer actually had, so `pendingWrite` now keeps each tracked max below the target (`lowMaxes`) and the classifier requires the offset to be within the read-back tolerance of one of them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(virtual-core): record a transient max below zero at 0 A row that shrinks the tracked max below zero leaves the element clamped at 0, not at the negative value, so a read-back at 0 after the sizer grew back matched no recorded max and retired the command. `lowMaxes` now records the reachable value (the element's 0, which is the hold in layout coordinates); the raw max still carries the next delta. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
nx run-many --targets=test:sherif,test:knip,test:docs,test:eslint,test:lib,test:e2e,test:types,test:build,build
⌘K
fix(virtual-core): keep an instant scroll command through a transient clamp (#1329)
Succeeded
in
4m 18s
Started
Linux
4 CPU cores
read
access token used
Copy command
nx run-many --targets=test:sherif,test:knip,test:docs,test:eslint,test:lib,test:e2e,test:types,test:build,build
main
d2c7911
GitHub
Open on GitHub
Tasks
Resource Usage
ta
TanStack
OSS