Interactivity API: Implement wp_initial_state()

[DAreRodz]

What?

Supersedes #56698
Tracking issue: #56803

Implements the wp_initial_state() function, a replacement for wp_store(), following the specification defined in the new store() API proposal. Extracted from the proposal:

If we move the derived state to the state property, there's no need to use the long wp_store format anymore: the state property can be absorbed in the function name (wp_initial_state) and the namespace can be passed as a string.

Instead of this:

wp_store( array(
  'state' => array(
    'myPlugin' => array(
      'someValue'  => 'some value',
      'someNumber' => 123,
    ),
  ),
  'selectors' => array(
    'myPlugin' => array(
      'someDerivedValue' => 'some derived value',
    ),
  ),
) );

We can write this and it will have the same information:

wp_initial_state( 'myPlugin', array(
  'someValue'        => 'some value',
  'someNumber'       => 123,
  'someDerivedValue' => 'some derived value',
) );

In addition, a system to handle store namespaces was added as required by wp_initial_state.

Why?

This function simplifies the way the initial state for interactive blocks is defined. Also, it is required to complete the migration to the new store() API.

How?

This PR implements the following:

• WP_Interactivity_Initial_State―a class with static properties and methods to handle the Interactivity API initial state globally.
• wp_initial_state()―a function that abstracts the usage of the aforementioned class.
• Support for namespaces defined via the data-wp-interactive directive.
• Support for custom namespaces in directive values, i.e., data-wp-text="custom-ns::state.prop".

Considerations

I think we could address the following items in subsequent PRs:

• Support for the derived state has been removed for now (see Interactivity API: Implement wp_initial_state() #57556 (comment)). We need to think of a way to add support again without passing anything as an argument, similar to what is done in the Interactivity API JS runtime.
• WP_Interactivity_Initial_State could be refactored to implement a singleton pattern instead of using static methods (if necessary).

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/experimental/interactivity-api/class-wp-interactivity-initial-state.php
❔ lib/experimental/interactivity-api/directives/wp-interactive.php
❔ lib/experimental/interactivity-api/initial-state.php
❔ phpunit/experimental/interactivity-api/class-wp-interactivity-initial-state-test.php
❔ lib/experimental/interactivity-api/class-wp-directive-processor.php
❔ lib/experimental/interactivity-api/directive-processing.php
❔ lib/experimental/interactivity-api/directives/wp-bind.php
❔ lib/experimental/interactivity-api/directives/wp-class.php
❔ lib/experimental/interactivity-api/directives/wp-context.php
❔ lib/experimental/interactivity-api/directives/wp-style.php
❔ lib/experimental/interactivity-api/directives/wp-text.php
❔ lib/load.php
❔ phpunit/experimental/interactivity-api/directive-processing-test.php
❔ phpunit/experimental/interactivity-api/directives/wp-bind-test.php
❔ phpunit/experimental/interactivity-api/directives/wp-class-test.php
❔ phpunit/experimental/interactivity-api/directives/wp-context-test.php
❔ phpunit/experimental/interactivity-api/directives/wp-style-test.php
❔ phpunit/experimental/interactivity-api/directives/wp-text-test.php

[DAreRodz]

@luisherranz, do you remember the idea we had for computing the derived state in the server? I added this comment just in case we want to change the current implementation (I'm pretty sure we want). 🤔

[luisherranz]

Let's remove support for closures for now.

[cbravobernal]

I added a small commit to prevent md5 and serializing when comparing blocks that are clearly not root.

• When the root blocks variable is null (no blocks have been added as a root block, or have been previosly added and compared, so that block won't be a root)
• When the name of the block is different than the name we previously saved as root block. If the block saved as root block has a different name than the one that we are comparing, we can skip the serialize + md5.

Feel free to revert in case you consider is better to wait for the PR to be merged.

[luisherranz]

Everything looks good to me 🎉 🎉

[youknowriad]

Has this been backported to Core already?

[cbravobernal]

Was refactored - backported here:
WordPress/wordpress-develop#5953