Skip to content

Add breadcrumbItems to menuData for custom breadcrumb rendering#704

Draft
kaevee wants to merge 1 commit intomoqui:masterfrom
kaevee:master
Draft

Add breadcrumbItems to menuData for custom breadcrumb rendering#704
kaevee wants to merge 1 commit intomoqui:masterfrom
kaevee:master

Conversation

@kaevee
Copy link

@kaevee kaevee commented Mar 17, 2026

Add breadcrumbItems to menuData for custom breadcrumb rendering

Problem

The header breadcrumb UI only had enough data to render the default path/title pattern. We need a way for screens to provide custom breadcrumb states and links.

Use Case

Some screens need custom breadcrumb trails (including intermediate links and non-link labels) that differ from default menu depth/title rendering, so users can navigate contextual paths correctly.

What Changed

  • Read optional screenBreadcrumbItems from the context stack.
  • Normalize breadcrumb entries to a safe list of maps containing:
    • title (required)
    • pathWithParams (optional; falls back from pathWithParams to path when available)
  • Ignore invalid/empty breadcrumb entries.
  • Attach normalized breadcrumbItems to the final menuData entry returned for the current target screen.

Data Contract

Input expected in context stack:

  • screenBreadcrumbItems: collection of maps
  • Each item may include:
    • title (string, required)
    • pathWithParams (string, optional)
    • path (string, optional fallback)

Output added to menuData last entry:

  • breadcrumbItems: list of { title, pathWithParams? }

Backward Compatibility

  • If screenBreadcrumbItems is absent or empty, no breadcrumbItems are added.
  • Existing consumers continue working unchanged.

Validation

Manual checks:

  1. Navigate to a screen with no custom breadcrumb data and confirm existing breadcrumb behavior is unchanged.
  2. Provide screenBreadcrumbItems with mixed linked/non-linked items and confirm output contains valid normalized entries.
  3. Confirm empty/invalid items are filtered out.

Out of Scope

  • Router/navigation internals are not changed in this PR.
  • The Quasar warning (Cannot read properties of undefined (reading 'catch')) is a separate pre-existing router shim issue.

Reviewer Focus

  • Is breadcrumbItems naming/shape acceptable for long-term API compatibility?
  • Is fallback logic (pathWithParams -> path) appropriate?
  • Any edge cases to harden before merge?

Related PR

- read optional screenBreadcrumbItems from the context stack
- normalize each breadcrumb to {title, pathWithParams}
- allow fallback from pathWithParams to path
- ignore invalid or empty breadcrumb entries
- attach breadcrumbItems to the final menuData map for WebrootVue consumers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants