[plugin] plugin to support WordPress Gutenberg specific blocks features (including how it injects window.React, window.wp.element, etc) within JSX decompilation

[0xdevalias]

Mostly creating this based on the exploration I did in #10 (comment) before I realised it was likely unrelated to more core React / JSX handling.

I suspect the bulk of this is niche enough that it wouldn't make sense to include in core, but would be a good candidate for a plugin as per #143 (comment) / #143 (comment)

This is also aligned to wakaru's proposed module-detection feature:

• Module detection pionxzh/wakaru#41

@j4k0xb I also don't expect this to be something you create; but figured since I already did the deeper exploration in this repo, I may as well create a standalone reference point for it, even if this issue ends up getting closed.

---

From my prior exploration:

Edit 2: Looking a bit deeper, I think window.wp.element relates more specifically to how the Wordpress Gutenberg editor may inject things:

• https://github.com/search?type=code&q=window.wp.element
• https://wordpress.org/gutenberg/
• https://github.com/WordPress/gutenberg
  • https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/
    • https://github.com/WordPress/gutenberg/tree/trunk/packages/create-block
      • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/es5/index.js.mustache#L9-L14
        • We can see wp.element.createElement / etc usage here
        • And where it's reading from window.wp here
          • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/es5/index.js.mustache#L71

Specifically in the 'plain JS' usage:

• https://github.com/hrsetyono/gutenberg-tutorial/blob/476f19ee0413ebf719df8981dc982b6aa5b64348/README.md?plain=1#L19-L31
• https://developer.wordpress.org/block-editor/getting-started/fundamentals/javascript-in-the-block-editor/#javascript-without-a-build-process

  • When you opt out of a build process, you interact directly with WordPress’s JavaScript APIs through the global wp object.

    • https://developer.wordpress.org/block-editor/reference-guides/packages/#using-the-packages-via-wordpress-global

      • JavaScript packages are available as a registered script in WordPress and can be accessed using the wp global variable.

    • https://www.npmjs.com/org/wordpress

So using window.wp.element would map to a version of @wordpress/element, provided by the backend through the window.wp global:

• https://github.com/WordPress/gutenberg/tree/trunk/packages/element
• https://developer.wordpress.org/block-editor/reference-guides/packages/packages-element/

Whereas in the non-static version, we can see that registerBlockType directly refers to the imported Edit / Save, which seem to handle their own imports, and/or use a JSX transform defined elsewhere in the build chain:

• https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/block/index.js.mustache#L26-L43
• https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/block/edit.js.mustache
• https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/block/save.js.mustache
• https://developer.wordpress.org/block-editor/getting-started/fundamentals/javascript-in-the-block-editor/#javascript-with-a-build-process

We can also see that the window.React global might come from Wordpress Gutenberg as well, as we can see from this example code that injects it:

• https://github.com/search?q=repo%3AWordPress%2Fgutenberg%20window.React&type=code
  • https://github.com/WordPress/gutenberg/tree/2103d5021066593f25f2baae9038b0cf23372b7f/packages/editor#blockcontrols
  • https://github.com/WordPress/gutenberg/tree/2103d5021066593f25f2baae9038b0cf23372b7f/packages/editor#richtext

We also get another clue here, where again window.React is injected into the function, and then a followup note to that:

• https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/docs/how-to-guides/plugin-sidebar-0.md#step-1-get-a-sidebar-up-and-running

  • For this code to work, those utilities need to be available in the browser, so you must specify wp-plugins, wp-editor, and react as dependencies of your script.

  • Here is the PHP code to register your script and specify the dependencies:

    function sidebar_plugin_register() {
    	wp_register_script(
    		'plugin-sidebar-js',
    		plugins_url( 'plugin-sidebar.js', __FILE__ ),
    		array( 'wp-plugins', 'wp-editor', 'react' )
    	);
    }
    add_action( 'init', 'sidebar_plugin_register' );

So I guess, similar to the comment made in #143 (comment), the deeper specifics of this may belong in a separate plugin instead of webcrack core.

Though.. I do wonder if the window.React (assigned to a variable) usage is generic enough that it might make sense to include in core?

• https://github.com/search?type=code&q=window.React

Originally posted by @0xdevalias in #10 (comment)

See Also

• [plugin] plugin to support unminifying goober CSS-in-JS library patterns + related JSX decompilation #152