fix(headless,headless-react): make ssr terminology more consistent

[btaillon-coveo]

https://coveord.atlassian.net/browse/KIT-2680

Here's a chart of the server-side-rendering flow:

sequenceDiagram
  participant Headless as @coveo/headless
  participant Static as Static definition
  participant SSR as Server-side
  participant CSR as Client-side
  alt Create definition
    Static->>+Headless: const definition = defineSearchEngine({ ... });
    Headless->>-Static: engine definition
  end
  CSR->>+SSR: request page
  alt Execute the first search
    SSR->>+Static: const stateA = definition.getStateA();
    Static->>SSR: First search response
    Static->>-SSR: State of every controller
  end
  alt render page
    SSR->>SSR: const html = generateHTMLFromState(stateA.controllers);
  end
  SSR->>CSR: send html
  SSR->>-CSR: send stateA
  CSR->>CSR: display HTML
  alt Obtain engine and controllers
    CSR->>+Static: const stateB = definition.getStateB(stateA.searchResponse);
    Static->>CSR: Search engine
    Static->>-CSR: Controllers
  end
  CSR->>CSR: subscribe to controllers

Loading

For StateA and StateB, we've been using inconsistent terminology.

In this PR, my goal is to align all the terms to be consistent. Here are the two main options we've been discussing:

• Option 1 (option I picked): for stateA, use "initial state" "static state". For stateB, use "hydrated state"
  • A file shared between both server and client calls defineSearchEngine, which returns an EngineDefinition<...>
  • The server calls fetchInitialState fetchStaticState
    • Returns an InitialState<...> StaticState<...>
  • The client calls hydrateInitialState hydrateStaticState
    • Takes an InitialState<...> StaticState<...> as a parameter.
    • Returns an HydratedState<...>
• Option 2: for stateA, use "ssrState". For stateB, use "csrResult"
  • A file shared between both server and client calls defineSearchEngine, which returns an EngineDefinition<...>
  • The server calls fetchSSRState
    • Returns a SSRState<...>
  • The client calls hydrateSSRState(?)
    • Takes a SSRState<...> as a parameter.
    • Returns a CSRState<...>

I picked option 1, since it feels more natural to me after all.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 2dadef5.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Manifest Files

[github-actions]

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

Bundle Size

File	Old (kb)	New (kb)	Change (%)
case-assist	182.1	182.1	0
commerce	266.2	266.2	0
search	348.5	348.5	0
insight	302.1	302.1	0
product-listing	290.8	290.8	0
product-recommendation	156.3	156.3	0
recommendation	195.6	195.6	0
ssr	210.3	210.2	0

[dmbrooke]

I like this language much more, it's very natural 🙂

[louis-bompart]

LGTM, better 💯

[mrrajamanickam-coveo]

Reads better overall!
Just a couple of places that got missed.

[btaillon-coveo]

Woops, missed those because I was doing a search and replace for SSR/CSR State to Static/Hydrated state.

Tried again, but this time used regular expressions like CSR([A-Z][a-z]*) -> Hydrated$1 and Static(?!State|Filter|CDN|Facet|Response|Resource)([A-Z][a-z]*) -> StaticState$1 to catch more. Of course, I didn't blindly approve every replacement.