feat(content-drive): merge base + content type filters into one chip

[zJaaal]

Summary

• Merges the separate Base Type and Content Type filters in the Content Drive toolbar into a single chip-style filter built on dot-chip-filter + <p-popover> + <p-listbox> (per [TASK] Content Drive: Migrate existent filters to chip + popover + listbox pattern #35490).
• Two-column popover: focus a base type on the left to filter the content-type list on the right; the right column also has a built-in search and lazy-loaded virtual scroll.
• Selected content types are pinned to the top of the right list so they remain visible across base-type focus changes.

Behavior

Selection cascade:

• Selecting a content type selects its parent base type.
• Unselecting the last content type of a base type drops the base type.
• Unselecting a base type drops all of its content types.
• Selecting a base type alone never auto-selects content types.

Chip label rules:

• Name (All) for a base type selected without narrowing.
• Specific content type names when the selection is narrowed.
• Mixed states combine both, e.g. Content (All), Blog Author.

Implementation notes

• Panel content is rendered inside @if ($popoverOpen()) so the listbox is recreated on each open. Without this, primeng's virtual scroll computes 0 visible items behind the hidden overlay and the right list never renders until clicked.
• Right list eagerly clears + immediately refetches on focus change (no debounce), which avoids stale items from the previous focus while the new fetch is in flight.
• A monotonically growing in-component cache lets $selectedContentTypes resolve full objects from the store even when those items are no longer in the visible page.
• Reverts the chip-filter clicked output to output<Event>() so consumers can pass the event into popover.toggle($event) for positioning.
• Tests drive every interaction through events on rendered elements (ngModelChange, onChange, onLazyLoad, onFilter, popover onHide, chip removed/clicked) — no protected-method bracket access.

Test plan

• Open the chip — popover renders, base types load on the left, content types on the right.
• Click a base type row (no checkbox) — right list refetches for that base type only.
• Click an empty checkbox in the left list — base type is added to selection; the chip shows Name (All).
• Pick a content type — both baseType and contentType are persisted to the store; the chip shows the content type name (no (All)).
• Unselect the last content type of a base — base type is dropped; the chip clears that segment.
• Select content types under different base types, then change focus — selected items remain pinned at the top of the right list.
• Type into the right search input — debounced server-side filter; (All) rows on the right respect the focused base type.
• Scroll the right list — lazy load fires, more pages are appended.
• Click the chip's X — all selections clear; both baseType and contentType are removed from the store.
• Click the toolbar "Clear all" — the chip empties.

🤖 Generated with Claude Code

[claude]

Claude finished @zJaaal's task in 5m 55s —— View job

---

PR Review

• Gather context
• Read main component files
• Read store and shared changes
• Post review findings

---

Issues Found

1. Panel-reopen data corruption after an active search (Bug)

onPanelHide resets contentTypeFilter to '' in state but leaves $state.contentTypes populated with whatever search results were loaded before closing. On the next open, @if ($popoverOpen()) recreates the DOM, virtual scroll fires onLazyLoad, which calls #loadContentTypes with the now-empty contentTypeFilter — appending unfiltered page-2 results onto stale filtered page-1 results.

dot-content-drive-content-type-filter.component.ts:359-362

protected onPanelHide(): void {
    this.$popoverOpen.set(false);
    patchState(this.$state, { contentTypeFilter: '' });  // data not cleared
}

Fix: also reset contentTypes: [], currentPage: 1, canLoadMore: true, loading: true on hide, and let the virtual-scroll onLazyLoad (which fires immediately on each open) drive the initial refetch. Fix this →

---

2. Spinner clears prematurely during concurrent search-debounce + focus-change (Bug)

If the user types (setting loading: true via the tap), then within 500 ms changes focus, the stale-guard branch in #setupFilterSubscription runs after the debounce and calls patchState(this.$state, { loading: false }) — while the focus-change HTTP call is still in-flight.

dot-content-drive-content-type-filter.component.ts:487-495

if (req.baseType !== currentType) {
    patchState(this.$state, { loading: false });  // ← fires while focus-fetch is in flight
    return EMPTY;
}

The spinner disappears before results arrive. Fix: only clear loading in the stale guard if no other fetch is in flight (e.g., by tracking an #isFetchingFocus flag). Fix this →

---

3. #hasMorePages divergence can trigger a spurious empty fetch (Minor)

Server-side totalEntries counts FORM and system content types before client-side filtering. When the last server page consists entirely of FORMs/system types, canLoadMore stays true after that page loads. The lazy loader fires again, gets an empty response from #filterContentTypes, and onLazyLoad then sets canLoadMore: false. This is a single extra API call per focus-change, not a loop — but it's a predictable extra round-trip.

dot-content-drive-content-type-filter.component.ts:550-554

#hasMorePages(pagination: DotPagination): boolean {
    const perPage = pagination.perPage || ITEMS_PER_PAGE;
    const totalPages = Math.ceil((pagination.totalEntries ?? 0) / perPage);
    return pagination.currentPage < totalPages;
}

The PR description acknowledges this but calls it "better than skewing the count client-side." That's true — just noting it triggers real extra traffic, not just a count mismatch.

---

4. #contentTypeCache grows without bound (Design)

#cacheContentTypes only appends, never evicts. In a large dotCMS installation, scrolling through all content types over a long session accumulates the full catalog in memory for the component's lifetime.

dot-content-drive-content-type-filter.component.ts:556-563

The PR description explicitly notes this as intentional to keep selected items resolvable. Acceptable as-is, but worth a comment about the trade-off and whether a max-size eviction policy (while preserving selected items) would be worthwhile.

---

5. Cascade-down on deselect-last-content-type drops the base entirely (Design concern)

When a user selects CONTENT in "all" mode, then adds Blog to narrow it, then removes Blog — the code drops CONTENT entirely rather than reverting to "all" mode. Compare with the checkbox path (onBaseTypeToggle partial→all): clicking a partial checkbox keeps the base in "all" mode. The two paths are asymmetric.

dot-content-drive-content-type-filter.component.ts:329-346

The PR description specifies this behavior explicitly. Flag it as a UX decision to verify with design: is "deselect last → drop base" really the intent, given the checkbox takes the opposite approach?

---

Minor observations (no action required)

• take(1) ordering: take(1) before takeUntilDestroyed in #loadContentTypes means the destroy-cleanup is effectively unreachable in the happy path (the observable completes after one value). Swapping the order (takeUntilDestroyed → take(1)) makes the intent clearer and ensures destroy correctly cancels in-flight calls. Currently it still works because takeUntilDestroyed wrapping take(1) propagates unsubscription upstream — but the intent is obscured.

• openPopover() test helper: relies on PrimeNG's popover.toggle() firing onShow synchronously in JSDOM. This works today but is brittle against PrimeNG upgrades that change overlay lifecycle timing. Directly setting spectator.component.$popoverOpen.set(true) would be more reliable.

• No retry UX on fetch failure: all catchError paths return of({ contentTypes: [], ... }) and silently show an empty list. A transient network blip leaves the user staring at an empty panel with no affordance to retry.