-
Notifications
You must be signed in to change notification settings - Fork 4k
[fix] No more sidebar flickering when initial_sidebar_state="collapsed" #11861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
✅ PR preview is ready!
|
28874b5 to
c6d1086
Compare
… sidebar behavior - Removed unused useRef for width initialization. - Integrated innerWidth from useWindowDimensionsContext to determine sidebar collapse state. - Updated useLayoutEffect dependencies to include innerWidth for better responsiveness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes a sidebar flickering issue when initial_sidebar_state="collapsed" by refactoring how sidebar collapse state is initialized and updated, and it bolsters coverage with both unit and end-to-end tests to prevent regressions.
- Refactor AppView to remove
useLayoutEffect/useRefin favor ofuseExecuteWhenChangedand simplify state initialization. - Add comprehensive unit tests in
AppView.test.tsxfor various sidebar initial states and transitions. - Introduce new E2E tests in
e2e_playwrightthat inject monitoring scripts to catch transient flickers during page load.
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| frontend/app/src/components/AppView/AppView.tsx | Refactored sidebar-collapse logic: removed legacy hooks, added useExecuteWhenChanged. |
| frontend/app/src/components/AppView/AppView.test.tsx | Added unit tests covering sidebar render and collapse/expand behavior. |
| e2e_playwright/st_sidebar_flicker_test.py | New E2E tests monitoring aria-expanded changes to detect sidebar flicker. |
| e2e_playwright/st_sidebar_flicker.py | Demo Streamlit app that drives the flicker tests via set_page_config. |
| e2e_playwright/multipage_apps_v2/mpa_v2_top_nav_test.py | Updated mobile navigation test to assert aria-expanded instead of visibility. |
| e2e_playwright/hello_app_test.py | Moved viewport setup calls to top of tests to stabilize sidebar state during resizing. |
Comments suppressed due to low confidence (2)
frontend/app/src/components/AppView/AppView.test.tsx:1288
- This test currently sets up the scenario but lacks assertions after simulating script finish; add checks or simulate
scriptFinishedHandlerto verify the sidebar override logic is applied as intended.
// Since we can't easily trigger the script finished handler in the test,
frontend/app/src/components/AppView/AppView.tsx:206
- [nitpick] Consider initializing
isSidebarCollapsedwith the result ofshouldCollapse(initialSidebarState, parseInt(activeTheme.emotion.breakpoints.md, 10), innerWidth)instead of a hardcodedtrue, so the UI won't briefly flash the wrong sidebar state before the effect runs.
const [isSidebarCollapsed, setSidebarIsCollapsed] = useState<boolean>(true)
| ) | ||
|
|
||
| const hasInitializedWidthRef = useRef(false) | ||
| const [isSidebarCollapsed, setSidebarIsCollapsed] = useState<boolean>(true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there is some logic outside of this PR I am missing, but if we initialize this as collapsed and update below to only update the collapsed state when the innerWidth changes, user clicks expand button, initial state changes, or theme changes, does this break the case that the initial state was expanded?
Or perhaps it doesn't break it because the innerWidth will always change as part of rendering? If this is right, it seems not ideal to rely on that inner width change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this logic definitely has room for improvement. I've filed a tech debt item to refine this behavior and clean it up. In the short term, I have this initialized to true because I didn't want to put the initialization logic that would be flawed upon first render when considering the inner width of 0. We could instead add conditional checks and initialize this as undefined if you feel that would be clearer.
lukasmasuch
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Describe your changes
This change fixes the bug linked below and adds a bunch of testing to ensure this doesn't happen again without us catching it. Additionally, it was discovered that there were some tests that were locking in this buggy behavior, so those have been updated as well.
GitHub Issue Link (if applicable)
This PR fixes #11848
Testing Plan
Added a new e2e test file as I felt it was merited to ensure this functionality doesn't regress. The test injects some javascript to look for any transient flickers that might occur that could be missed by playwright.
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.