PoC: RRM Gutenberg Blocks

[nfmohit]

Summary

Addresses issue:

• Add RRM inline CTA button blocks #9963

Relevant technical choices

This is a PoC that implements one of the RRM Gutenberg blocks.

PR Author Checklist

• My code is tested and passes existing unit tests.
• My code has an appropriate set of unit tests which all pass.
• My code is backward-compatible with WordPress 5.2 and PHP 7.4.
• My code follows the WordPress coding standards.
• My code has proper inline documentation.
• I have added a QA Brief on the issue linked above.
• I have signed the Contributor License Agreement (see https://cla.developers.google.com/).

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Code Reviewer Checklist

• Run the code.
• Ensure the acceptance criteria are satisfied.
• Reassess the implementation with the IB.
• Ensure no unrelated changes are included.
• Ensure CI checks pass.
• Check Storybook where applicable.
• Ensure there is a QA Brief.
• Ensure there are no unexpected significant changes to file sizes.

Merge Reviewer Checklist

• Ensure the PR has the correct target branch.
• Double-check that the PR is okay to be merged.
• Ensure the corresponding issue has a ZenHub release assigned.
• Add a changelog message to the issue.

[techanvil]

Having to reach into assets like this makes me think blocks should have been a subdirectory of assets/js, after all these are still JS assets... And, it would be more closely aligned with the workspace structure.

Maybe one to discuss with the team and/or at the next eng leads sync...

Cc @tofumatt @eugene-manuilov @aaemnnosttv

[eugene-manuilov]

@techanvil @nfmohit CORE_MODULES and registerStore should be imported from googlesitekit-* package like we do it with googlesitekit-data. If we can't do it right now, then we need to update our assets to be able to do that. Then we will need to add the rrm module script as a dependency to this block script.

[techanvil]

@eugene-manuilov, I'm not sure we want to include the full googlesitekit-modules-reader-revenue-manager JS asset on the posts page, as it will contain code and components that we don't want to and indeed can't use due to the differing React versions between our NPM-installed @wordpress/element and that of the external @wordpress-core/element (and possibly some other dependency version clashes).

It could arguably be worthwhile though, either if the commonalities between the RRM block editor asset and the main RRM module grow large enough, or we just figure that browser-side caching of the asset makes it efficient to reuse on the posts page anyway.

If so, we'll need to restructure the asset to avoid unwanted initialisation that is not relevant to the posts page.

If we decide to keep the two separate, it would still be nice to figure out a way to import from googlesitekit-* packages, but we'd probably need to introduce packages and entry points for shared RRM and other relevant module code.

[nfmohit]

Thank you for the input here, folks!

As we have a working PoC with the assets not restructured, let's go ahead and use them as they are now. Let's revisit this on our next engineering leads sync. Thanks!

[techanvil]

@nfmohit I suspect we'll need to add execution => defer to this asset, as I found it was needed for the initial asset in my PoC, this was to ensure the store was correctly initialised regardless of whether the Admin Bar is enabled or not.

site-kit-wp/includes/Modules/Reader_Revenue_Manager.php

Lines 433 to 445 in 8699cc7

	$assets[] = new Script(
	'googlesitekit-reader-revenue-manager-block-editor',
	array(
	'src' => $base_url . 'js/googlesitekit-reader-revenue-manager-block-editor.js',
	'dependencies' => array(
	'googlesitekit-data',
	'googlesitekit-i18n',
	'googlesitekit-modules',
	),
	'load_contexts' => array( Asset::CONTEXT_ADMIN_POST_EDITOR ),
	'execution' => 'defer',
	)
	);

[nfmohit]

Updated, thanks Tom!

[techanvil]

@nfmohit, I think these imports should come from @wordpress-core/element to avoid mixing code/components from different versions of React...

[nfmohit]

Good point, updated, thanks Tom!

[techanvil]

@nfmohit, just to be clear is the expectation that the real button content will always be this text in English?

Asking for clarity and also because the button styling would not accommodate a longer piece of text...

[nfmohit]

Good question. In the actual button that renders in the front end, the text is populated by the swg-basic.js library, so it is not translatable, not at least from our end. The swg-basic.js library does populate the button with text using a different language if the site language is different, but since we don't load swg-basic.js in the editor, we can't replicate that. Do you think we should make it translatable for our editor preview?

[techanvil]

Thanks @nfmohit. Seeing as the actual button will be rendered with text in the site's language, I think we should do our best to translate it in the editor too.

I'd suggest making the text translatable and linking to the list of titles for the relevant button in the translators hint, e.g. here for the Contribute button.

The styling will also need modifying to better handle variable width text.

[nfmohit]

I agree, I've updated the button accordingly, thanks Tom!