feat: add vault overview accordions#617
Conversation
Wrap vault overview sections in reusable accordion cards with configurable default open states across standard, pair, and Securitize views.
railway-app
Bot
temporarily deployed
to
euler-lite / euler-lite-pr-617
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: euler-xyz/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA reusable ChangesVault Overview Accordion Refactor
Possibly Related PRs
Suggested reviewers
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed: dependency version conflict. Check your lock file or package.json. Comment |
|
🚅 Deployed to the euler-lite-pr-617 environment in euler-lite
|
…15-convert-vault-page-sections-to-accordion-style # Conflicts: # components/entities/vault/overview/SecuritizeVaultOverview.vue # components/entities/vault/overview/VaultOverview.vue # components/entities/vault/overview/VaultOverviewBlockGeneral.vue
railway-app
Bot
temporarily deployed
to
euler-lite / euler-lite-pr-617
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
components/entities/vault/overview/VaultOverviewBlockIRM.vue (1)
615-622: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy liftLazy-load the IRM chart when this section starts collapsed.
This accordion only hides the panel DOM; it does not stop the existing
onMounted/watch-drivenVaultLensandUtilsLensreads from running immediately. That turns a default-collapsed technical section into eager off-screen RPC + chart work. Consider wiring the fetch/render path to the expanded state, or hoisting the accordion above this component so the IRM body mounts only after expansion.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/entities/vault/overview/VaultOverviewBlockIRM.vue` around lines 615 - 622, The Interest rate model section currently mounts its VaultLens/UtilsLens data and chart work even when the accordion starts collapsed, so make the IRM body lazy by tying the fetch/render path to the expanded state in VaultOverviewBlockIRM and the accordion section around hasValidIRM/defaultOpen. Update the onMounted/watch-driven reads so they only run after expansion, or move the conditional mounting above this component so the IRM content does not mount until the section is opened.components/entities/vault/overview/VaultOverviewBlockOracleAdapters.vue (1)
305-309: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy liftKeep oracle adapter loading behind expansion for collapsed views.
After this refactor the section can start closed, but
loadOracleAdapter(...)anduseOracleAdapterPrices(...)still fan out as soon as the component mounts. In the pair overview this block is explicitly default-closed, so users still pay the metadata/price-loading cost before opening it. Please gate that work on the accordion’s open state, or move the accordion above this component so the expensive body mounts lazily.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/entities/vault/overview/VaultOverviewBlockOracleAdapters.vue` around lines 305 - 309, The Oracle adapters section still triggers eager metadata/price loading on mount even when the accordion is collapsed. Gate the expensive work in VaultOverviewBlockOracleAdapters.vue behind the accordion’s open state, or restructure so the body that calls loadOracleAdapter(...) and useOracleAdapterPrices(...) only mounts when the VaultOverviewAccordionSection is expanded. Keep the change centered on the accordion/open-state logic and the Oracle adapters loading flow.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@components/entities/vault/overview/VaultOverviewBlockIRM.vue`:
- Around line 615-622: The Interest rate model section currently mounts its
VaultLens/UtilsLens data and chart work even when the accordion starts
collapsed, so make the IRM body lazy by tying the fetch/render path to the
expanded state in VaultOverviewBlockIRM and the accordion section around
hasValidIRM/defaultOpen. Update the onMounted/watch-driven reads so they only
run after expansion, or move the conditional mounting above this component so
the IRM content does not mount until the section is opened.
In `@components/entities/vault/overview/VaultOverviewBlockOracleAdapters.vue`:
- Around line 305-309: The Oracle adapters section still triggers eager
metadata/price loading on mount even when the accordion is collapsed. Gate the
expensive work in VaultOverviewBlockOracleAdapters.vue behind the accordion’s
open state, or restructure so the body that calls loadOracleAdapter(...) and
useOracleAdapterPrices(...) only mounts when the VaultOverviewAccordionSection
is expanded. Keep the change centered on the accordion/open-state logic and the
Oracle adapters loading flow.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: euler-xyz/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d411ddb6-2ec1-428a-8f06-c8cbb521b894
📒 Files selected for processing (16)
components/entities/vault/overview/SecuritizeVaultOverview.vuecomponents/entities/vault/overview/SecuritizeVaultOverviewPair.vuecomponents/entities/vault/overview/SecuritizeVaultOverviewPairBlockGeneral.vuecomponents/entities/vault/overview/VaultOverview.vuecomponents/entities/vault/overview/VaultOverviewAccordionSection.vuecomponents/entities/vault/overview/VaultOverviewBlockAddresses.vuecomponents/entities/vault/overview/VaultOverviewBlockBorrow.vuecomponents/entities/vault/overview/VaultOverviewBlockCyclicalIRM.vuecomponents/entities/vault/overview/VaultOverviewBlockGeneral.vuecomponents/entities/vault/overview/VaultOverviewBlockIRM.vuecomponents/entities/vault/overview/VaultOverviewBlockOracleAdapters.vuecomponents/entities/vault/overview/VaultOverviewBlockRiskParameters.vuecomponents/entities/vault/overview/VaultOverviewBlockStats.vuecomponents/entities/vault/overview/VaultOverviewPair.vuecomponents/entities/vault/overview/VaultOverviewPairBlockGeneral.vuecomponents/entities/vault/overview/VaultOverviewPairBlockTypes.vue
LeonardEulerXYZ
left a comment
LeonardEulerXYZ
left a comment
There was a problem hiding this comment.
Leonard review — PR #617
Verdict: COMMENT — no blocking issues found on the reviewed head dccb4d0c31afc7b9eb51b307f93e2dfeb56b5c12.
Walkthrough
This PR converts the vault overview surfaces into shared accordion sections:
- Standard lend vault overview: Overview/Statistics remain open; deeper technical sections default closed.
- Borrow pair overview: pair Overview remains open; Vault types and Oracles default closed.
- Securitize vault and pair variants receive the same accordion treatment.
VaultOverviewAccordionSectioncentralizes the section chrome, native button toggling,aria-expanded, and optional action slot handling.
Risk assessment
The changed surface is user-visible but mostly layout/state presentation rather than transaction logic. The main risks I checked were:
- hidden/closed sections accidentally dropping important risk data;
- mobile overview drawer behavior diverging from desktop;
- section actions/footnotes being swallowed by the accordion button;
- accessibility regressions around the accordion trigger state;
- one-off accordion wrappers creating inconsistency across sibling overview variants.
No blocking regression found.
Validation performed
npm run test:run— 95 files / 958 tests passed.npm run typecheck— passed.npm run build— passed; only existing-style Vite/Rollup chunk/dynamic-import warnings observed.npx eslint <changed vault overview files>— passed.- Headed/Xvfb Playwright browser visual smoke against the PR preview:
- desktop lend vault deep link: KPK VBILL/USDC lend vault, accordion headers/content present.
- desktop borrow pair deep link: KPK VBILL/USDC borrow/multiply pair, pair overview and oracle accordion present.
- mobile lend vault deep link: opened the
Vault informationdrawer and verified the accordion content is reachable there. - desktop accordion interaction check: default-open/default-closed
aria-expandedstates matched intent; expandingRisk parameterschangedaria-expandedfromfalsetotrue.
Smoke coverage: browser visual smoke + mobile smoke. Wallet/signing smoke: not run; this PR does not change transaction preparation or wallet signing paths.
Visual evidence
Screenshots are from the public PR preview and contain only public app UI:
Scalability / maintainability hygiene pass
I searched the sibling overview surfaces that consume the same vault overview data and UI concept:
- covered by this PR: standard vault overview, standard borrow pair overview, Securitize vault overview, Securitize pair overview, addresses/stats/risk/IRM/oracle/type blocks;
- genuinely out of scope: Earn overview blocks under
components/entities/vault/overview/earn, which are a separate Earn-specific overview surface and not mentioned by the PR intent; - reusable abstraction: the shared
VaultOverviewAccordionSectionis the right direction and avoids per-block button/chrome duplication; - focused tests: there is no dedicated component-level accordion test, but the wrapper is small, uses native button semantics, and the repo’s current test suite is not component-render focused. I do not think this is a blocker for this layout refactor.
One non-blocking follow-up worth keeping in mind: CodeRabbit’s performance note is valid. VaultOverviewBlockIRM and VaultOverviewBlockOracleAdapters can still do chart/oracle loading while their accordion sections start collapsed, because the accordion hides the panel body inside an already-mounted component. That does not break correctness, and I would not block this PR on it, but if the product goal includes reducing first-load work rather than only reducing visual density, the next clean step is to hoist lazy mounting above those expensive bodies or expose accordion open state to gate those fetches.
Bot/reviewer feedback pass
I inspected the active CodeRabbit review. Its two notes about eager IRM/oracle loading behind collapsed accordions are materially valid but non-blocking performance/architecture follow-ups; I did not duplicate them as inline Leonard findings.
Comment lifecycle
No prior Leonard-authored top-level comments, reviews, or inline review comments were present for this PR head, so there was nothing to edit or clean up.
Collapse a vault overview accordion by default when it is the only accordion section in its parent view.
railway-app
Bot
temporarily deployed
to
euler-lite / euler-lite-pr-617
Force a lone vault overview accordion section open after mount so single-section views show their content by default.
railway-app
Bot
temporarily deployed
to
euler-lite / euler-lite-pr-617
Keep accordion actions before a far-right chevron so sections with badges retain the same expand affordance as other rows.
railway-app
Bot
temporarily deployed
to
euler-lite / euler-lite-pr-617
Make the full vault overview accordion header toggle the section while keeping header actions independently clickable.
2 participants
Summary
Changes
Test plan
git diff --check.Summary by CodeRabbit