fix(web): keep sidebar stable after settings - #7744
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
One finding: the new disable() + one-frame enable() sequence cancels auto-animate's initial coordinate bootstrap, so the first real thread-list change after each sidebar mount replays enter keyframes instead of a FLIP move. Details inline.
Posted via Macroscope — UI Consistency
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Straightforward UI stability fix that prevents sidebar flicker when returning from Settings. Changes add a read-only subscription hook (matching existing pattern) and defer animation setup to skip irrelevant mutations. Limited scope, clear intent, no business logic impact. You can add or adjust custom eligibility rules. Learn more. |
What Changed
Why
Settings swaps the thread sidebar out of the React tree. The existing retention component only kept projects subscribed, so thread shells could briefly rebuild when the user returned.
There was a second contributor:
DndContextinstalls accessibility nodes just after the list mounts. FormKit interpreted those setup mutations as new content and applied its 225 ms scale/fade animation to every existing thread row. Attaching auto-animate one frame later treats that work as initial rendering without disabling real list animations.Fixes #7743.
Related: #5930, #6480.
UI Changes
This defect is visible only during the Settings -> Back transition, so short recordings are used instead of still screenshots.
Before
The existing sidebar rows briefly disappear, then scale and fade back in.
sidebar-settings-before.mp4
After
The existing rows remain stable when returning from Settings.
sidebar-settings-after.mp4
Verification
vp run --filter @t3tools/web typecheckvp fmt --check apps/web/src/components/AppSidebarLayout.tsx apps/web/src/components/Sidebar.tsxmain: Settings -> Back briefly emptied and scaled/faded the existing row.Checklist
Built with GPT-5.6 Codex in T3 Code.
Note
Keep sidebar stable after settings by retaining thread projections and deferring auto-animate
ProjectProjectionRetentiontoSidebarProjectionRetentionand addsuseThreadShells()so thread-related projections stay subscribed when the thread sidebar is swapped out (AppSidebarLayout.tsx)autoAnimateattachment by onerequestAnimationFramein the Sidebar list, skipping immediate setup mutations and destroying the controller on detach or ref changes (Sidebar.tsx)attachListAutoAnimateRefnow relies onrequestAnimationFrameand node connectivity checks; if the list node disconnects before the frame fires, auto-animate will not attachMacroscope summarized dafb19e.
Note
Low Risk
UI-only subscription and animation-timing tweaks; no auth, data, or API changes. Worst case is a missed first-frame auto-animate attach if the list unmounts before rAF.
Overview
Stops the thread sidebar from emptying and animating existing rows when returning from Settings.
Keeps thread-shell projections subscribed (alongside projects) while Settings unmounts the sidebar, so lists do not flash empty while the environment snapshot reconnects.
Defers FormKit
autoAnimateon the thread list by one frame soDndContextaccessibility setup is not treated as new content. Later add/remove/layout animations stay enabled.Reviewed by Cursor Bugbot for commit dafb19e. Bugbot is set up for automated code reviews on this repo. Configure here.