fix(block-editor): server-side search for content-type & contentlet pickers

[rjvelazco]

Proposed Changes

Fixes #36487 — the new Block Editor's content-type picker only showed the first 40 content types (alphabetical) and couldn't find the rest by scroll or search; the contentlet drill-down had the same limitation.

Root cause: the slash-menu submenu fetched once with an empty query (perPage: 40) and filtered client-side. The legacy editor re-queried the server on each keystroke, so any record was findable. This restores that behavior.

What changed:

• SlashMenuService — new openAsyncSubmenu(search, commandFn): rows come from a debounced (250ms) server search that re-runs on every keystroke. Includes a stale-response token guard, consecutive-query dedupe, and timer/level-switch/close teardown. filterItems routes to the server search when in async mode. Removed the now-dead openSubmenu() / setItems() (the one-shot-fetch + client-filter path).
• slash-menu-catalog — both picker levels use openAsyncSubmenu. buildContentletByTypeQuery now accepts the search term and builds a Lucene-escaped, tokenized query (ported from the legacy getContentlets, incl. UUID handling), so contentlet search is server-side too.
• Sub-menu re-anchor fix (follow-up commit) — update() now refreshes the caret anchor (clientRectFn) in sub-menu mode too. Previously it was discarded there, so once the query text changed while searching, the overlay stayed pinned to the root menu's now-detached suggestion decoration node (getBoundingClientRect() → ~0,0) and the menu jumped to the top-left of the editor. A pre-existing bug that the new search box surfaced (multi-word queries in the sub-menu).

No fixed page-size cap → scales to instances with 2000+ content types. Empty/error/loading states, keyboard nav, and node insertion are preserved.

Checklist

• nx run new-block-editor:lint passes (type-checked)
• Server-side debounced search wired for both picker levels (content types + contentlets)
• Sub-menu overlay re-anchors to the caret while searching (no top-left jump)
• Manual verification pending — needs a running instance with >40 content types:
  • / → Content → confirm the full type list searches server-side (types past the old 40-cap, e.g. MM… / RTL…, are findable)
  • pick a type → confirm contentlet search works server-side
  • type a multi-word query → confirm the menu stays anchored under the caret (positioning fix)
  • verify rapid typing (debounce / stale-response) behaves
  • (Could not runtime-verify in the authoring env: no local nx serve, no seeded backend.)

Additional info

• Customer report: Freshdesk #38277.
• Related: [BUG] Multiple Block Editor fields in a content type share state, causing menus to misbehave #35908 (Block Editor 2.0 parity), epic Block Editor 3.0: standards, accessibility & feature parity #35262.

🤖 Generated with Claude Code

This PR fixes: #36487

[claude]

Claude finished @rjvelazco's task in 13m 8s —— View job

---

Code Review

Reviewed the full diff against origin/main — service state machine, catalog query builder, the sub-menu re-anchor fix, and both new specs. The core design (debounced server search, token guard, dedupe, teardown on close()) is sound and the query builder faithfully mirrors the legacy getContentlets Lucene logic. Kevin's brace-style note is addressed (commit 45cc25a6).

One non-blocking gap below.

New Issues

• 🟡 Medium: slash-menu.service.ts:172 / 291-305 — Pending debounce timer + in-flight search are not torn down when the editor is destroyed. close() clears submenuSearchTimer and bumps the token, but the service has no OnDestroy and detachEditor() (called from the slash extension's onDestroy) doesn't touch the timer. If the editor is destroyed while a sub-menu search is debouncing (user typing in the picker, then the field/editor unmounts), the setTimeout still fires ~250ms later → runSubmenuSearch calls search(query) (an HTTP request) and the stale guard passes because isInSubmenu is still true and the token still matches — so it sets signals on a service belonging to a destroyed component. Orphaned request + post-destroy state write. Low frequency, but the fix is small: clear the timer (and bump the token) in detachEditor(), or implement OnDestroy and call the same teardown as close(). Fix this →

Notes (non-blocking)

• slash-menu.service.ts:299 — scheduleSubmenuSearch flips isLoading to true immediately, so the spinner shows for the full 250ms debounce while the previous rows stay visible. Acceptable UX; flagging only so it's intentional.
• slash-menu-catalog.ts:47-49 — escapeLucene/UUID_LIKE/LUCENE_SPECIAL_CHARS are duplicated verbatim from the legacy suggestions.service.ts. The PR description already acknowledges this is deliberate pending a shared @dotcms/data-access util — no action needed now, but worth a tracking ticket so the two copies don't drift.
• Test coverage is good: the query-builder spec pins the exact Lucene strings (UUID, multi-word, hyphen, escaping, trim) and the service spec exercises the debounce, dedupe, and the out-of-order stale-response guard. The one path not covered is the destroy/teardown case in the finding above.

Everything else — the token/isInSubmenu stale guard, the empty/error row handling, keywords[0] variable round-trip, and the update() caret re-anchor — checks out.

• issue-36487-block-editor-content-type-picker-40-limit

[rjvelazco]

@claude can you review this code, pretty please

[claude]

Review in progress

• Gather context (PR diff, files, description)
• Read slash-menu.service.ts changes
• Read slash-menu-catalog.ts changes
• Review for bugs, security, performance, maintainability
• Post review feedback

View job run

[rjvelazco]

Thanks for the review. Addressed the one actionable finding — added the first specs in new-block-editor (commit adds slash-menu-catalog.spec.ts + slash-menu.service.spec.ts, 12 tests, all green):

• buildContentletByTypeQuery — asserts the exact Lucene strings for empty, single-word, multi-word, hyphenated, UUID, special-char escaping, and trimming (mirrors the legacy suggestions.service spec). Exported the builder for direct testing.
• SlashMenuService.openAsyncSubmenu — jest.useFakeTimers() tests for the initial search, 250 ms debounce coalescing, consecutive-query dedupe, the stale-response token guard (out-of-order resolution — the exact off-by-one risk you called out), and close() dropping a late response.

Re your notes: agreed on all — query-builder parity, escaping, and the async state machine were the design intent, and the escapeLucene/UUID_LIKE duplication is deliberate (no legacy-lib dependency) pending a shared @dotcms/data-access util. Manual runtime verification (positioning + >40-type search) is still on the checklist for a reviewer with a seeded instance.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request