Size Change: 0 B

Total Size: 1.19 MB

_{compressed-size-action}

Thank you for looking at React Fast Refresh. Do you think it would be possible to find a general approach to all pages that use the block editor? This PR covers only the edit site page.

Block editors are initialized by WordPress injecting inline scripts to the page. This prevents us from using HMR, that's why we have a separate hot.js file.

On the other hand, post editor is initialized in WordPress core: https://github.com/WordPress/WordPress/blob/5da8c0fcebf0b7cab6d1821be8f464f4428f942f/wp-admin/edit-form-blocks.php#L417-L425 which makes things even more complicated.

We can add HMR to Widgets and Navigation editor the same way we do for the Site editor, but the post editor is complicated since we don't have any filters that we could use to manipulate the initialization of the editor.

It's a very challenging task to make React Fast Refresh work with WordPress in general. It might work at the moment to ignore the wp globals for the edit site but it raises the question of how far it can get. It makes it impossible to enable any plugins that reference wp.element or any other variable under wp global, in practice most of them either use those globals directly or use @wordpress/scripts which does it during bundling. Some functionalities might not work as well, like Block Directory integration (might not be enabled yet) or RichText formatting controls:

• gutenberg/lib/edit-site-page.php

  Line 173 in 273dee2

  wp_enqueue_script( 'wp-format-library' );

  
  It's also unclear what happens to all modification applied to blocks on the server:
  

  gutenberg/lib/edit-site-page.php

  Lines 147 to 157 in 273dee2

  	wp_add_inline_script(
  	'wp-blocks',
  	sprintf( 'wp.blocks.unstable__bootstrapServerSideBlockDefinitions( %s );', wp_json_encode( get_block_editor_server_block_settings() ) ),
  	'after'
  	);
  	wp_add_inline_script(
  	'wp-blocks',
  	sprintf( 'wp.blocks.setCategories( %s );', wp_json_encode( get_block_categories( $post ) ) ),
  	'after'
  	);

  
  As you can see it isn't only wp.apiFetch but other modules as well.

I'm pretty sure we have limitations on how far we can go. On the other hand, HMR works well if we are developing in the core. It'd save us a lot of time. Refreshing after all the changes vs refreshing after 10% of the changes.

We could run this as an experimental feature and see how useful it is. If it's breaking too many times then we can revert it anytime.

Not sure if this is useful, but devs from Vue, Preact, and Snowpack collaborated to make a bundler-independent HMR spec. It looks like the only implementation so far is Snowpack's, though.

#25077 is somewhat related, since that could -- but wouldn't have to -- involve switching to a modern bundler. That might make this easier (including beyond the Site Editor, so that plugins could use it too).

See #28273 (comment). I have a working proof of concepts for React Fast Refresh with @wordpress/scripts for block development.