Block Bindings: do not use useSource hook conditionally

[retrofox]

What?

This pull request enhances the mechanism by which block attributes are bound to external source properties. The primary aim is to prevent calling React hooks in the wrong way, in this case, conditionally.

On this PR:

• Component Introduction: Two new components, <BlockBindingBridge /> and <BlockBindingConnector />, have been introduced. These components isolate and encapsulate connecting block attributes with external source properties.

• Hook Invocation Improvement: To circumvent the issue of incorrect hook invocation within a loop, the source object is now passed down to the <BlockBindingConnector />. This ensures that the hook is called at the top level of the component, aligning with React's best practices.

• API Modification: The useSource() API has changed. Previously, a useValue method was provided, but it has been removed in favor of directly exposing the source property's value and its handler through value and updateValue props, respectively. The updated API structure is as follows:

export default {
  name: 'namespace/source-handler',
  label: 'The custom namespace source-handler',
  useSource: (blockProps, sourceArgs) => {
    // Logic to fetch value
    const value = getFromWherever();
    const updateValue = () => {};
    // Expose value and its updater
    return {
      placeholder,
      value,
      updateValue,
    };
  }
};

Why?

Because calling the hook wrongly is not recommended. It could bring performance issues.

How?

This PR addresses the issue by introducing and components to streamline the connection between block attributes and external sources, thereby preventing incorrect hook calls. It refines the useSource() API to directly expose the source property's value.

Testing Instructions

Pretty similar to #58085

0. Register a new custom field however you prefer. You can use a snippet similar to this:

register_meta(
	'post',
	'text_custom_field',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
		'default'	   => 'This is the content of the text custom field',
	)
);
register_meta(
	'post',
	'url_custom_field',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
		'default'	   => 'https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg',
	)
);

Test paragraph

1. Add a paragraph with the content connected to a custom field:

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"text_custom_field"}}}}} -->
<p>Value provided by the source (core/post-meta)</p>
<!-- /wp:paragraph -->

3. Confirm it isn't possible to edit the block content.
4. Confirm that if the meta text_custom_field value is defined ((001) Meta value in my testing block), then it should be shown in the UI:

[gziolo]

Code-wise it is looking good enough to include in WP 6.5 RC1. I will do some testing to ensure it all works as expected.

[SantosGuillamot]

Not 100% related to this pull request, but it will affect once this other one gets merged.

There is an issue with the fallback value that is solved by this refactoring. However, we will need to update the e2e tests after the mentioned PR is merged. We'll have to update these lines to have "fallback value": line 1, line 2, & line 3.

[gziolo]

Everything tests well for me, and I also see that all e2e tests on CI pass which means we should be good to go.

There is still a tiny issue that is also present in trunk that I hoped this PR would also resolve. However, I prefer we explore it separately. I included a screencast with CPU throttling enabled at 6x, but it might still need watching the video at slower pace:

Screen.Recording.2024-02-28.at.12.51.50.mov

That might be specific to the Query Loop block and its implementation. We can observe that when changing the active post, the whole Post Template renders from scratch, and in that case, you can see the fallback value stored in HTML for blocks, which gets replaced in the next render with the value coming from the source.

The great news is that the fallback loaded from the saved content is never replaced with the value from the source, which is the intended behavior I advocated to have in the WP 6.5 release.

[SantosGuillamot]

As explained in this comment, I've updated the tests in this commit now that the mentioned PR has been merged.

[SantosGuillamot]

There is still a tiny issue that is also present in trunk that I hoped this PR would also resolve. However, I prefer we explore it separately.

I have just pushed this commit that should solve the blinking effect. At least until we figure out a better solution.

[youknowriad]

I just cherry-picked this PR to the update/packages-6.5-rc1 branch to get it included in the next release: e88f867