fix: follow gradual item resizes when maintaining scroll at end - #507
fix: follow gradual item resizes when maintaining scroll at end#507focux wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 28112f1b1c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| state.maintainingScrollAtEnd = undefined; | ||
| if (state.pendingMaintainScrollAtEnd) { | ||
| doMaintainScrollAtEnd(ctx); | ||
| doMaintainScrollAtEnd(ctx, options); |
There was a problem hiding this comment.
Preserve the options of the coalesced maintain request
When an animated data-change maintain is in its 500 ms settling window and an item resize arrives, the latter only sets the boolean pendingMaintainScrollAtEnd, so this callback replays it with the first call's options (undefined). The resize therefore becomes another animated, frame-deferred maintain instead of the intended { animated: false, immediate: true }, retaining the delayed correction this change is meant to fix. Conversely, a data-change request queued behind an instant resize inherits the resize options and loses its configured animation; the pending state needs to retain or merge the options of the request being coalesced.
Useful? React with 👍 / 👎.
Description
When an item in an end-anchored list (
maintainScrollAtEnd+onItemLayout) resizes gradually — e.g. a Reanimated layout animation growing a chat row a few px per frame — the end anchor fails to follow: each step is under the 5px threshold inupdateItemSizes, and when a delta does qualify,doMaintainScrollAtEnddefers to a rAF + animated scroll with a 500ms settling lock. Measured on a 240fps recording of our chat app: the growing row sits clipped below the viewport for ~500ms, then catches up in uneven 2–8px steps.Two changes:
prevSizeKnown !== undefined(kept). Since ff3f8c7,isNativeLayoutNoisealready rejects sub-pixel noise before this check, so 5px only swallows real resizes. The check now reuses that epsilon.{ animated: false, immediate: true }— a measured resize is already the real layout, so follow it synchronously instead of racing a 500ms scroll animation against the growth. Omitted options preserve current behavior; the data-change path (checkResetContainers) is untouched.Related: #492.
Tests
Options coverage in
doMaintainScrollAtEnd(immediate skips rAF,animated: falseoverrides, defaults unchanged) and threshold coverage inupdateItemSize(~2px known-item resize flags maintenance, sub-epsilon doesn't). 1516 pass / 0 fail, Biome clean.Disclaimer: The fix was made by Claude Code using Fable and it fixes some issues we had on our chat list.