[plugin] plugin to support WordPress Gutenberg specific blocks features (including how it injects `window.React`, `window.wp.element`, etc) within JSX decompilation
Mostly creating this based on the exploration I did in https://github.com/j4k0xb/webcrack/issues/10#issuecomment-2693645060 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 https://github.com/j4k0xb/webcrack/issues/143#issuecomment-2692345330 / https://github.com/j4k0xb/webcrack/issues/143#issuecomment-2692517232
This is also aligned to wakaru's proposed module-detection feature:
- https://github.com/pionxzh/wakaru/issues/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.elementrelates 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.wphere
- 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
wpobject.
- 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
wpglobal variable.- https://www.npmjs.com/org/wordpress
So using
window.wp.elementwould map to a version of@wordpress/element, provided by the backend through thewindow.wpglobal:
- 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
registerBlockTypedirectly refers to the importedEdit/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.Reactglobal 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.Reactis 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, andreactas 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 https://github.com/j4k0xb/webcrack/issues/143#issuecomment-2692345330, the deeper specifics of this may belong in a separate plugin instead of
webcrackcore.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 https://github.com/j4k0xb/webcrack/issues/10#issuecomment-2693645060
See Also
- https://github.com/j4k0xb/webcrack/issues/152