Merge new SSR state on client-side navigation

[DAreRodz]

Currently, the store state is initialized once (during hydration). However, when client-side navigation happens, it could contain newly defined state for the new HTML that should not be ignored.

We need to read and merge the new state into the current state, keeping the props it already has.

[luisherranz]

To document here how to deal with this state merge:

• If the state should be updated after client-side navigation, the developer won't have to do anything because it will be the default behavior.

  For example, imagine there is a state.myPlugin.pageLikes property with the number of likes of a certain page. That number will come populated from the server, and can be updated if the user clicks on the "Like" button. When the user navigates to another page, the state.myPlugin.pageLikes property must be replaced with the number of likes of the new page, populated again from the server.

• If the state should not be updated after client-side navigation, the developer needs to create an additional property that is only present on the client (and therefore it won't be updated).

  For example, imagine a state.myPlugin.input property that populates an input and differs depending on each page. Users can edit the input; the input value should not change when they navigate to another page.

  In this case, the recommendation would be to rename the property to state.myPlugin.initialInput, and use it to populate a client-only state.myPlugin.input that won't be updated when both states are merged.

[luisherranz]

This is a pattern that people could use when they want to ignore the new server value of some state property and preserve the one that is in the client, but make it transparent for the state mutators/consumers:

wp_initial_state([
  "initialNumberOfItems" => 3
]);

const { state } = store("myPlugin", {
  state: {
    currentNumberOfItems: null,
    get numberOfItems() {
      return state.currentNumberOfItems ?? state.initialNumberOfItems;
    },
    set numberOfItems(value) {
      state.currentNumberOfItems = value;
    },
  },
  action: {
    addOneItem: () => {
      // Consumers/mutators can always use `state.numberOfItems`
      state.numberOfItems += 1;
    },
  },
});

[luisherranz]

I've just noticed that you don't need an extra client property because, with the first call to the setter, you can override both the setter and getter.

You do need the setter, though. Without it, JS won't override the getter, and TS will complain that the prop is read-only.

wp_initial_state([
  "initialNumberOfItems" => 3
]);

const { state } = store("myPlugin", {
  state: {
    get numberOfItems() {
      return state.initialNumberOfItems;
    },
    set numberOfItems(value) {
      state.numberOfItems = value;
    },
  },
  action: {
    addOneItem: () => {
      // Consumers/mutators can always use `state.numberOfItems`
      state.numberOfItems += 1;
    },
  },
});

This is pretty cool 🙂

[Spekachu]

That is pretty cool, thanks! I am curious about loading/merging the required styles from blocks used on other pages, when using client-side navigation. Is that possible? Im fetching the page content of a client-side navigated page and displaying the rendered content, which happens to be woocommerce products. Some of the block styles come through, but not all of them. If I refresh the page, then all the required styles come through.

[DAreRodz]

Hey! Let's continue the conversation here. 😊

[DAreRodz]

I'm closing this discussion as the SSR state merge was solved in the following PR:

• Interactivity API: Fix navigate() issues related to initial state merges #57134