fix(layout): UpdateBanner re-mount on nav causes the 'page jump' MAPPS-203 reports #191
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
psa-systems/mokosh-apps!191
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/mapps-203-update-banner-no-shift-on-nav"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The user-reported symptom is the sidebar scrolling to the top + the whole page jumping on every nav click. Source-of-truth investigation found there is no separate 'payments banner' the issue body hypothesised; the actual offender is the existing UpdateBanner whose layout-shift behaviour on first paint PMS-313 fixed but whose behaviour on every subsequent navigation it did not.
Each page in the SPA wraps its content in a fresh AppLayout, which re-mounts the UpdateBanner from scratch. The banner's local use_resource therefore starts at None every time, dropping into BannerState::Reserving (the 1fr-tall invisible row PMS-313 added so the first paint already has the banner's height reserved). One tick later the fetch resolves to 'no update' and state flips to Collapsed, which animates the row from 1fr to 0fr over 200ms via the grid-template-rows transition. That collapse is exactly the layout shift the user sees every time they click a nav item.
Fix: lift the result of GET /api/v1/version into a context signal owned by App (new hooks/version_cache.rs, mirroring the use_sidebar_provider pattern). The UpdateBanner reads the cache first; when it carries Some(result) the banner derives its final state (Show or Collapsed) directly with no Reserving step and no transition. The component's own use_resource still runs on each re-mount so the banner refreshes on every nav, and a use_effect writes the resolved result through to the cache so the next re-mount benefits. Only the App's first-ever admin mount sees None on both signals, so PMS-313's first-paint reserved-height behaviour is preserved exactly as before; every subsequent admin nav skips it.
#MAPPS-203