A facet value in the search URL shows as selected but is not applied until the reader toggles it

[jamiefolsom]

What happens

Open an items search with a facet value in the URL, the form the stacked timeline's "Filtered search" bar link produces:

https://gwc.performant.studio/en/search/items/?786ddc04-3d48-45c9-8555-fe4bc4619509.name_facet[0]=Roman%20Egypt

The filter panel shows the badge "1", the chip "Geopolitical Context: Roman Egypt", and the Roman Egypt checkbox ticked, with a count of 34 beside it. But the result list is not narrowed: it shows 266 results, including items from other contexts such as the Adysh Gospels (Asia Minor and Caucasus).

Untick the Roman Egypt checkbox and the count changes to 250; tick it again and the list narrows to the expected 34 items (Bankes Homer, Codex Alexandrinus, and so on). So the refinement is only applied once the reader touches it.

Why it matters

The stacked timeline embed's "Filtered search" link sends readers to exactly this kind of URL, so the feature Paul Dilley was promised (click a timeline bar, see the items from that geopolitical context) lands on a page that looks filtered but is not. Until this is fixed the link mode should not be switched on for client sites.

Where to look

The search state is restored from the URL by the routing returned by TypesenseUtils.createRouting (core-data package) and the refinement widgets are mounted by Facets.tsx in this repo. The initial UI state reaches the widgets (the checkbox renders ticked) but the search parameters sent to Typesense do not include the refinement on the first request. Seen at v1.11.0 with core-data 3.1.25.

Related: performant-software/gwc-content#11.

[jamiefolsom]

Root cause found and a fix is written, pending review.

The cause is in the core-data package's progressive search hook, not in the routing. InstantSearch re-renders widgets with the previous results while a new search is in flight, and it patches _state on that previous results object to the current state (its optimistic UI). The hook decides whether to reset or merge its hit cache by comparing results._state with the last state it saw, so after the URL facet is applied it resets the cache to the stale unfiltered hits and then merges the real filtered hits into them. On Global Writing Cultures that produced 250 unfiltered items plus 16 new Roman Egypt items, the 266 reported above.

The fix decides from the results object identity and its page number instead, which come from the response rather than from the patched state. It is on a branch in react-components with unit tests and was verified on a local dev server: the facet URL lands on the filtered count, unfiltered paging still loads every page, and toggling a facet by hand still works. The pull request and the dependency bump here follow.

[jamiefolsom]

The fix is up for review as performant-software/react-components#610. Once it is released, this repo needs the core-data dependency bumped to pick it up.