feat: rely on state in getWidgetRenderState

[francoischalifour]

Description

This changes how we provide the widgets' render state from the helper state to the retrieved state (renderOptions.helper.state vs. renderOptions.state).

This is required to support React InstantSearch Hooks SSR¹ to avoid flashes between SSR and CSR² when hydrating.

Explanation

As opposed to Vue InstantSearch SSR, React InstantSearch Hooks SSR works in a single data flow pass. We rely on a single helper (the one created by InstantSearch.js), to provide the search state and the search results to the widgets.

By design, InstantSearch.js computes the search parameters from the mounted widgets (e.g., searchBox controls the query search parameter). As soon as you start setting a search parameter that is not yet controlled by a widget (this happens when a child index inherits from its parent index searchBox state), InstantSearch isn't able to take control back on that search parameter. This is for this reason that we cannot override the helper state (aka search parameters) before widgets are mounted, and then rely on the widgets to update the helper state again.

Because of this constraint, once we override the initial helper state on SSR, any interactions on the browser won't update the search parameters, leaving the UI stuck.

This PR modifies the way we return the widgets' render state from getWidgetRenderState to rely directly on state, and not helper.state. This lets us provide a computed initial state from results._state without controlling the search parameters yet, and display the correct UI state on screen without messing with InstantSearch internals. And therefore lets InstantSearch correctly controls the search parameters after user interactions.

Impact

This change is only internal and shouldn't impact any user implementations.

Footnotes

1. SSR: Server-Side Rendering ↩

2. CSR: Client-Side Rendering ↩

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit f3a5a73:

Sandbox	Source
InstantSearch.js	Configuration

[Haroenv]

I wonder if in the index widget, could we make the getter of helper.state warn? Or is that still used internally on eg. setState?

[francoischalifour]

There are still valid use cases for using helper.state in callbacks like createURL() or refine() to manipulate the latest helper state:

https://github.com/algolia/instantsearch.js/blob/7747c50c037b1a73cf74e9e82986a0c303822e5a/src/connectors/breadcrumb/connectBreadcrumb.ts#L204-L206

An ESLint rule should be able to catch that maybe? Not really trivial though. Ultimately we want the values from the main paths that are returned from getWidgetRenderState to be computed with state, not with helper.state, the rest is fine.

[Haroenv]

this change lgtm, as even if we fix this issue in React InstantSearch server side rendering later, state should be consistent with helper.state.

In a future version I'd like to see state being the same as helper.state though, and maybe even only one of the two exposed

[Haroenv]

this is what caused the bug (state is stale in this callback), but the part of code isn't actually needed, we can still set the query and search without condition. Fixing in #4990