What?

Fixes: #65243

Exposes getServerState() and getServerContext() from the @wordpress/interactivity package.

These functions return an object that is analogous to the state/context returned by store()/getContext(), with a couple of differences:

• The object returned is read-only.
• The object is updated after navigate() calls, using the values defined in the HTML.
• Devs cannot directly use its properties in directives, but they can use callbacks to subscribe to changes in its properties and update the usual state/context.

Example:

import { store, getServerState } from '@wordpress/interactivity';

const { state } = store('myStore', {
  callbacks: {
    updateServerState() {
      const serverState = getServerState();
      // Override some property with the new value that came from the server.
      state.overridableProp = serverState.overridableProp;
    },
  },
});

Why?

These functions are required for subscribing to changes in state/context when the HTML is updated using navigate().

How?

Both the state and the context use proxifyState() internally, a function that wraps objects with proxies and handles all the reactivity and property subscriptions. This function has been extended to accept a { readOnly } option that, when true, prevents any modification to the given object and nested ones.

The objects returned by getServerState() and getServerContext() use readOnly: true, and it's the function deepMerge(), refactored in #64879, the one that updates the server state and the server context.

The function populateServerData() has been changed to update the server state. As that function is already used in navigate(), no changes in @wordpress/interactivity-router were required.

Lastly, the implementation of the data-wp-context directive has been adapted to handle the server context updates and inheritance.

Testing Instructions

I've added unit tests and e2e tests.