fix(uve): QA feedback on prevent breadcrumb from showing stale title during navigation

[adrianjm-dotCMS]

Fixes #35807

What changed

dot-ema-shell.component.ts

• Replaced untracked(() => this.uveStore.pageParams()?.url) with full URL construction via pageFriendlyParams() + normalizeQueryParams() + router.createUrlTree(), producing a proper clickable /dotAdmin/#/edit-page/content?... breadcrumb link instead of just the raw page path
• Added early-return guard if (!this.uveStore.pageParams()) return null inside untracked to prevent a crash in headless configs where uveConfig.url is set — normalizeQueryParams calls new URL(params.clientHost) which throws if pageParams was cleared by resetPageParams() before the effect is torn down

dot-ema-shell.component.spec.ts

• Updated 3 existing URL assertions to match the #/edit-page/content?... format; one uses stringMatching to verify the /dotAdmin/# prefix
• Replaced the stale-data-during-LOADING test with a navigation accumulation test that explicitly asserts the breadcrumb is not called during LOADING and is called exactly once with the new page data after LOADED
• Existing destroy-race test (resetPageParams() + cycle uveStatus) still covers the null-pageParams crash path

Test plan

• Navigate between pages in the UVE — breadcrumb should show the correct title after each navigation
• Click a breadcrumb link — should navigate back to the correct page in the editor
• Open and close the UVE — no console errors

This PR fixes: #35807

[claude]

Claude finished @adrianjm-dotCMS's task in 2m 54s —— View job

---

Review

• Read PR context
• Read changed files
• Review for bugs, risks, edge cases
• Post review

Overall: The refactor from effect() + untracked() to computed + signalMethod is a clean expression of intent (signalMethod is purpose-built for "react to a signal source"). The crash fix and URL-construction fix both look correct. A few notes worth a second look:

🟡 Latent bug papered over, not fixed

normalizeQueryParams (libs/portlets/edit-ema/portlet/src/lib/utils/index.ts:526-531) calls new URL(params.clientHost) whenever baseClientHost is truthy — with no guard against params.clientHost being undefined. The component now adds if (!this.uveStore.pageParams()) return as a defensive fence, but the utility itself remains fragile. Any other caller in a headless config that passes empty params will hit the same crash. Consider a params?.clientHost && guard in the util as a follow-up.

🟡 Breadcrumb URL captures the current sub-tab, not always /content

this.#router.createUrlTree([], { queryParams }) (line 222) builds the URL from the current router state. If the breadcrumb effect fires while the user is sitting on /edit-page/layout (e.g., after a page reload while on the layout tab), the breadcrumb's clickable URL becomes /dotAdmin/#/edit-page/layout?..., not /dotAdmin/#/edit-page/content?... as the PR description claims. The test (expect.stringMatching(/^\/dotAdmin\/#.*url=index/)) is loose enough not to catch this. Is this intentional (return user to where they were) or should the URL be pinned to content? Worth verifying in QA on layout/rules tabs.

🟡 Test name oversells the assertion

The new test is named "should replace breadcrumb on navigation, not accumulate stale entries" (spec.ts:1164), but the assertion is toHaveBeenCalledTimes(1) — that proves the component fires once with fresh data and not during LOADING, not that the breadcrumb list is replaced rather than appended. Replacement vs. accumulation is decided by GlobalStore.addNewBreadcrumb's shouldReplaceLastCrumb logic (breadcrumb.feature.ts:164), which is outside this PR. Either rename the test to match what it asserts (e.g., "should not call addNewBreadcrumb during LOADING and call it once after LOADED") or add a separate assertion against globalStore.breadcrumbs() to actually cover the "no stale accumulation" claim.

✅ Things that look right

• The destroy-race test (resetPageParams() + cycle uveStatus) still covers the null-pageParams crash path — good.
• signalMethod from @ngrx/signals 21.0.1 wraps the processor in untracked internally, so reading pageParams() / pageFriendlyParams() inside the body won't create unwanted reactive deps — the source is exclusively $breadcrumbPage.
• $breadcrumbPage correctly gates on status === LOADED, so the LOADING → LOADED transition naturally fires the method once per navigation. Stale data during LOADING is filtered out.
• Tests updated consistently with the new /dotAdmin/#... URL format.

Minor / nits

• The Spanish comment block from the original was dropped — the new version is more readable, no objection.
• Constructor wiring (this.$updateBreadcrumb(this.$breadcrumbPage)) is the standard signalMethod pattern and runs in injection context. ✓
  • Branch