1

I want to create a Gutenberg block that uses React on the client rendered page (not the admin pages).

  • Is React code split from the rest of Gutenberg?

  • If so, how can I enqueue that specific bundled React to be used?

Improve this question
7
  • gutenberg is a post editor, it doesn't load on the frontend, and neither does the React code you write for your block. When the post is saved, any react used to save it generates static HTML and that static HTML is what goes in the database and gets shown on the frontend. If you want to use React in a block on the frontend it would be no different to if you wanted to use React in a shortcode or React in a widget on the frontend. You'd need to create a separate React JS app, JS bundle, separate enqueue, etc
    – Tom J Nowell ♦
    Commented Feb 25, 2023 at 15:15
  • I understand all that, though I would sure assume I’m not the only one that would like React to be available on the client. And if every block that wants to use it for interactivity bundles their own copy, that’s a bad practice and will ship unnecessarily redundant code.
    – lookyhooky
    Commented Feb 25, 2023 at 19:36
  • not really because nothing in your save component can be interactive unlike the frontend, and your edit component is fundamentally different to your frontend component. Anything shared would be in a separate shared package. Also look at the official recommended way to build blocks WP Scripts that automatically extracts WordPress packages and enqueues them instead so your bundle doesn't get built with duplicate copies. It also doesn't make sense to enqueue all the editor packages and libraries along with the frontend
    – Tom J Nowell ♦
    Commented Feb 25, 2023 at 20:35
  • I understand that all the data of the block is contained in the editor and not available to the front end, unless exposed through the JSON API. All I’m looking for is a way to share a common bundle of React across multiple block plugins. There are plenty of reasons to create interactive experiences that don’t need access to the editor, but can be placed in a document by an editor.
    – lookyhooky
    Commented Feb 25, 2023 at 21:04
  • that's also not true, block attributes are saved to the database and available in PHP filters. You can also include that data as data attributes in your saved markup
    – Tom J Nowell ♦
    Commented Feb 26, 2023 at 11:11

1 Answer 1

Reset to default
1

I found it, wp-element. The @wordpress/scripts should handle the heavy lifting of transforming the JSX in the proper way.

add_action( 'wp_enqueue_scripts', 'my_enqueue_plugin_js' ); // Loads on frontend

function my_enqueue_plugin_js() {
    wp_enqueue_script(
      'my-plugin-frontend',
      plugin_dir_url( __FILE__ ) . 'js/plugin.js',
      ['wp-element']
    );
}

Once we do this we will have window.wp.element available in our JavaScript. This contains the ReactDOM render() function as well as createElement() if you wanted to write React without JSX.

-- How to Enqueue React in A WordPress Theme or Plugin

Improve this answer
5
  • note that WP Element is just a wrapper, it was written at a time when the core teams weren't 100% sure they would stick with React in the future and wanted to insulate themselves from compatibility breaks or library changes. You'll see early talk about the block editor sometimes justifies using WP Element to build block UI's with Vue JS. For frontend use this may not be optimal
    – Tom J Nowell ♦
    Commented Feb 26, 2023 at 11:13
  • I feel confident that Gutenberg isn't about to pivot away from React. So I'm going to try this out and see how far I can take it. It seems like a better solution than using JQuery or vanilla JavaScript to recreate interactively of a Gutenberg block on the frontend.
    – lookyhooky
    Commented Feb 26, 2023 at 13:31
  • FYI I am enquiring with the Gutenberg team on this question too. I will keep this question/answer up to date as I learn more.
    – lookyhooky
    Commented Feb 26, 2023 at 13:33
  • i agree, since that time it's pretty firmly stuck to React, but the block editor is showing a representation of the frontend, not the literal same thing. E.g. a hyperlink in the block editor isn't a real hyperlink, and a slider wouldn't make sense as it would auto-play to the next slide as you're trying to type into it. That's not to say it isn't possible to use WP packages on the frontend, but the idea that your edit/save/frontend components should all be the same code sounds ideologically and architecturally appealing at first, but they become a nightmarish mess quickly
    – Tom J Nowell ♦
    Commented Feb 26, 2023 at 13:48
  • you also shouldn't interpret anything I said as not using React on the frontend, there's nothing wrong with import ... from 'react'; in a bundle intended for the frontend
    – Tom J Nowell ♦
    Commented Feb 26, 2023 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.