refactor(ui): show pill navbar only on root pages#474
refactor(ui): show pill navbar only on root pages#474
Conversation
When VITE_DEV_NSEC is set in .env.local, automatically initializes the wallet on dev server startup, bypassing onboarding and unlock screens.
The pill navbar was a fixed overlay requiring manual padding on every
component with bottom-positioned elements. Since all action buttons
live on sub-pages (Send, Receive, Settings options), hiding the navbar
on sub-pages eliminates the conflict entirely.
- Show navbar only on Wallet home, Apps home, and Settings menu
- Hide with spring animation (Framer Motion) on sub-page navigation
- Remove footer clearance CSS hacks and manual padding workarounds
in ButtonsOnBottom and Delegates
- Disable pointer-events on hidden navbar to prevent click blocking
Files: App.tsx, PillNavbarOverlay.tsx, ButtonsOnBottom.tsx,
Delegates.tsx, index.css, ionic.css
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughApp now computes navbar visibility from navigation + settings option and passes a new Changes
Sequence DiagramsequenceDiagram
participant App as App.tsx
participant Nav as PillNavbarOverlay
participant Motion as Framer Motion
App->>App: compute isSettingsRoot & showNavbar (screen + option)
App->>Nav: render with visible = showNavbar
alt visible = true
Nav->>Motion: animate to {opacity: 1, y: 0}
Motion-->>Nav: mount visible layer
Nav->>Nav: ensure interactive (no inert / pointer-events)
else visible = false
Nav->>Motion: animate to {opacity: 0, y: 24}
Motion-->>Nav: collapsed/hidden
Nav->>Nav: apply inert and hidden class (disable pointer-events)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
Deploying wallet-bitcoin with
|
| Latest commit: |
9018fcb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d838a397.wallet-bitcoin.pages.dev |
| Branch Preview URL: | https://wt-navbar-root-only-20260325.wallet-bitcoin.pages.dev |
Deploying wallet-mutinynet with
|
| Latest commit: |
9018fcb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://77abdacf.arkade-wallet.pages.dev |
| Branch Preview URL: | https://wt-navbar-root-only-20260325.arkade-wallet.pages.dev |
- Keep master's authState/unlockWallet additions in App.tsx and wallet.tsx - Keep master's .scroll-fade opt-in selector for scroll mask - Remove footer clearance rule (our change) that master re-added
🔍 Arkana PR Review —
|
The navbar visibility check used `screen` from NavigationContext, which lags behind the actual rendered page. When the app is locked, `screen` stays as Pages.Wallet while `page` is overridden to Pages.Unlock, causing the navbar to appear on the unlock screen. Add `page === screen` guard so the navbar hides whenever the rendered page is overridden (unlock, loading). Also add `inert` to the hidden navbar overlay for accessibility, and stub VITE_DEV_NSEC in tests to prevent env-dependent flakiness.
|
Iterative review — Good improvement. The key change in const isSettingsRoot = screen === Pages.Settings && option === SettingsOptions.Menu
const showNavbar = page === screen && (screen === Pages.Wallet || screen === Pages.Apps || isSettingsRoot)The New tests cover all three cases (unlock, loading, authenticated root) — solid coverage. Minor: the LGTM ✅ |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/test/App.test.tsx (1)
193-235: LGTM!The new test suite provides solid coverage of the navbar visibility logic:
- Tests the
page !== screenguard (unlock overrides wallet screen).- Tests the loading hold scenario.
- Tests the happy path for authenticated users on root pages.
Consider adding tests for Apps and Settings root pages if not covered elsewhere, to ensure parity with the Wallet root test.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/App.test.tsx` around lines 193 - 235, Add two new tests mirroring the Wallet root test to cover Apps and Settings roots: use renderApp with authState: 'authenticated' and initialized: true and set screen/tab to Pages.Apps/Tabs.Apps and Pages.Settings/Tabs.Settings respectively; then await screen.findByTestId('ion-app') and assert ionApp.className contains 'has-pill-navbar'. Place them alongside the existing Navbar visibility tests and reuse the same test setup (beforeEach stubbing detectJSCapabilities, matchMedia, vi.stubEnv) so renderApp, Pages, and Tabs symbols are referenced exactly as in the current suite.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/test/App.test.tsx`:
- Around line 193-235: Add two new tests mirroring the Wallet root test to cover
Apps and Settings roots: use renderApp with authState: 'authenticated' and
initialized: true and set screen/tab to Pages.Apps/Tabs.Apps and
Pages.Settings/Tabs.Settings respectively; then await
screen.findByTestId('ion-app') and assert ionApp.className contains
'has-pill-navbar'. Place them alongside the existing Navbar visibility tests and
reuse the same test setup (beforeEach stubbing detectJSCapabilities, matchMedia,
vi.stubEnv) so renderApp, Pages, and Tabs symbols are referenced exactly as in
the current suite.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e8c4b040-9af2-4fe7-a4b1-f929222d99a2
📒 Files selected for processing (5)
src/App.tsxsrc/components/PillNavbarOverlay.tsxsrc/index.csssrc/ionic.csssrc/test/App.test.tsx
💤 Files with no reviewable changes (1)
- src/ionic.css
🚧 Files skipped from review as they are similar to previous changes (1)
- src/components/PillNavbarOverlay.tsx
With the navbar hidden on sub-pages, payment success screens (send, receive, notes) were dead ends with no way to navigate home. Adds a ButtonsOnBottom "Sounds good" button that navigates to wallet.
|
Iterative review — Straightforward fix for the dead-end problem: Send, Receive, and Notes success screens now have a Consistent across all three screens, correct imports. No concerns — this was the expected follow-up from hiding the navbar on sub-pages. LGTM ✅ |
1 participant
Summary
page === screenguard ensures the navbar is hidden whenever the rendered page is overridden (unlock, loading hold)inerton hidden navbar — when the navbar is hidden, it's removed from the accessibility tree and tab order4rempadding inButtonsOnBottom, manualpill-navbar-clearancepadding inDelegates.tsxVITE_DEV_NSECauto-init feature (separate commit) for faster local dev iterationWhy
The pill navbar was a fixed overlay (
position: fixed, portaled todocument.body) that required every component with bottom-positioned elements to manually account for its height. This was brittle — three CSS variables, automatic padding onIonContent, margin onIonFooter, conditional padding inButtonsOnBottom, and manual padding inDelegates.tsx.Since all action buttons exist on sub-pages and never on root pages, hiding the navbar on sub-pages eliminates the conflict entirely.
The navbar was also appearing on the Unlock screen because the visibility check used
screenfrom NavigationContext (which could still bePages.Wallet) instead of the actual renderedpage. Addingpage === screenas a guard fixes this.Success screens (send, receive, notes) became dead ends after hiding the navbar on sub-pages — no navbar, no back button, no way out. Added a "Sounds good"
ButtonsOnBottombutton on each that navigates back to wallet home, following the same pattern asInit/Success.tsx.Note for reviewers
The
isSettingsRootcheck inApp.tsxcouples navbar visibility toOptionsContext.option. This means if someone refactors Settings sub-navigation, they need to be aware it affects navbar visibility. Worth considering whether this should live in the navigation system instead (e.g., exposeisRootPagefromNavigationContext). @pietro909 thoughts?Test plan
Summary by CodeRabbit
Style
New Features
Tests