Unified search: the v2 <SearchResults> component + host consumer

[habdelra]

The one v2 search component family, <SearchResults @query=… />, plus the host-side pieces it needs. Phase 1 of the unified-search project. Additive — it sits alongside the existing prerendered-card-search component and the live SearchContent tree; no call site is migrated in this PR (each surface migrates as its own shippable step).

What it does

<SearchResults> consumes the heterogeneous search-entry stream from getSearchEntriesResource and renders it transparently:

• a prerendered html rendering shows inert (the fast path) and hydrates lazily on interaction (hover/click/touch, or none),
• an item-only row renders as a live card.

Each result is a RenderableSearchEntry exposing id / isError / html / item / component. The component wraps the merged HydratableCard mechanism, so a consumer renders <entry.component /> without ever branching on prerendered-vs-live — that's what makes the split transparent. It's curried in JS via the same custom-manager pattern html-component.ts already uses to yield a renderable .component; provide/consume context still reaches the nested HydratableCard because the glimmer VM tracks context per component instance regardless of manager.

Used with a block it yields a results object (entries / isLoading / meta / errors); used without one it renders the default stream of entry.components itself.

<SearchResults @query={{this.query}} as |results|>
  {{#each results.entries key='id' as |entry|}}
    <entry.component />
  {{/each}}
</SearchResults>

Selective Store inflate

StoreService.inflateSearchEntryItem deposits only full item serializations (so a by-URL read or the hydration GET resolves without a round-trip). A sparse item (one carrying meta.sparseFields) and the search-entry itself are never deposited — a sparse item would misrepresent the instance and could clobber a correctly-loaded full one. <SearchResults> runs this as a render-side effect over the live entry set, so an item-bearing row deposits whenever one lands on a re-run.

Render type

An html row hydrates/renders as the type its rendering carries; an item-only fallback renders as the query's requested ancestor (echoed once in the document meta) so it matches its HTML siblings; files render natively. View-models are memoized by the resource's stable entry identity, so a live re-run never re-mounts an unchanged row's component.

Tests

tests/integration/components/search-results-test.gts (7 tests, all green against the realm stack):

• prerendered HTML renders inert and hydrates into a live card on hover;
• a heterogeneous stream renders the html row inert and the item-only row live;
• selective inflate — a full item is deposited, a sparse item never is;
• the component inflates a full-item row into the store;
• an error rendering never hydrates;
• the block-yield shape (results.entries / meta / each entry.component);
• an idle query renders nothing, then activates when set.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1ac96da3a4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Preview deployments

• Host staging preview

• Host production preview

Host Test Results

    1 files      1 suites   1h 52m 2s ⏱️
3 073 tests 3 058 ✅ 15 💤 0 ❌
3 092 runs  3 077 ✅ 15 💤 0 ❌

Results for commit 619531d.

Realm Server Test Results

    1 files      1 suites   10m 17s ⏱️
1 715 tests 1 715 ✅ 0 💤 0 ❌
1 808 runs  1 808 ✅ 0 💤 0 ❌

Results for commit 619531d.

[Copilot]

Pull request overview

Adds the first “unified search” v2 <SearchResults @query=… /> component family for host usage, providing a single render surface for heterogeneous search-entry results (prerendered inert HTML that hydrates lazily, plus item-only rows that render live), along with the supporting host-side selective Store inflation behavior and integration tests.

Changes:

• Introduces <SearchResults> (block-yield or default rendering) that wraps each entry in a ready-to-render <entry.component /> abstraction.
• Adds a curried hydratableEntryComponent() wrapper around HydratableCard using a custom component manager (similar to html-component.ts).
• Adds StoreService.inflateSearchEntryItem() to selectively deposit only full item serializations (skipping sparse ones) into the Store, plus integration coverage.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
packages/host/app/components/card-search/search-results.gts	New v2 SearchResults component: entry view-modeling, default vs block rendering, render-side selective inflate.
packages/host/app/lib/hydratable-entry-component.ts	New curried component wrapper that renders HydratableCard with per-entry args via a custom manager.
packages/host/app/services/store.ts	Adds inflateSearchEntryItem() that skips sparse items and inflates full items into the store from search data.
packages/host/tests/integration/components/search-results-test.gts	New integration tests covering inert HTML, hydration, heterogeneous streams, and selective inflation behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.