PoC: Pulling JavaScript to the frontend from a Core Block. #29537
Conversation
|
Size Change: 0 B Total Size: 1.41 MB ℹ️ View Unchanged
|
| @@ -121,6 +121,14 @@ function render_block_core_navigation( $attributes, $content, $block ) { | |||
|
|
|||
| unset( $attributes['rgbTextColor'], $attributes['rgbBackgroundColor'] ); | |||
|
|
|||
| wp_enqueue_script( | |||
| 'core_block_navigation_load_modals', | |||
| plugins_url( 'gutenberg/build/modals/index.js' ), | |||
There was a problem hiding this comment.
I'd love for this to be something like frontend_script in the register_block_type server side (kind of like the editor_script we already have), having the declarativness should allow us later to support lazy loading these scripts only when the block is used.
There was a problem hiding this comment.
What would be the difference with script that already exists and can be rendered on both the front-end and in the editor? How about CSS? Should it follow it?
There was a problem hiding this comment.
I'm not aware of it, could you point me to an example?
There was a problem hiding this comment.
What would be the difference with script that already exists and can be rendered on both the front-end and in the editor? How about CSS?
General tradeoffs here are loading unnecessary JS/CSS on the frontend (we typically end up needing some specific editor only handling for a block) vs potentially having drifting implementations.
There was a problem hiding this comment.
The idea was to have script and editorScript, where script works with both the front-end and the editor because you are building the same experience. The same applies to style vs editorStyle.
There was a problem hiding this comment.
The
WPDefinedAssettype is a subtype of string, where the value represents a path to a JavaScript or CSS file relative to whereblock.jsonfile is located.
The JS file should be next to block.json and CSS files in the build folder:
So it'd be:
{
"script": "file:./front.js "
}The existing usages of
editorStylewithin Gutenberg are all pointing to the name of a registered style.
It's only temporary because @aristath couldn't make it work with the file reference because some features were missing in the WordPress core. There might be more reasons, but we definitely want to use file references everywhere.
There is also an important consideration. The folder structure needs to be portable to the WordPress core as it is going to use the same block.json and other files.
There was a problem hiding this comment.
One more thing, in #22754, we added logic that automatically enqueues the file defined with script on the front-end when the block is rendered. It was also backported to the WordPress core:
There was a problem hiding this comment.
It's only temporary because @aristath couldn't make it work with the file reference because some features were missing in the WordPress core. There might be more reasons, but we definitely want to use file references everywhere.
I've added logic to webpack so that script.js gets built in the correct place, and tested loading it through block.json — it works fine, so I've removed the script registration for now.
Pathing feel a bit hardcod-y, but it works fine as the only blocks we're interested in here are in the block-library package.
There was a problem hiding this comment.
One more thing, in #22754, we added logic that automatically enqueues the file defined with
scripton the front-end when the block is rendered. It was also backported to the WordPress core:
The following comment indicates that the optimization made there does not keep assets loaded through block.json from being loaded everywhere for Core Blocks.
The assets associated with core block's are always enqueued (source). Thus, they won't be able to take advantage of the optimizations here. At a minimum, the core blocks should be updated to reference the script and style asset handles themselves, rather than creating an ad hoc enqueuing implementation. This should serve as a simplifying refactoring, and ensure consistent behavior of assets enqueuing for all blocks.
- A separate effort should seek to try to split the core blocks' script and style assets to per-block assets. In the meantime, there's not much benefit to these optimizations for core blocks.
I compared both approaches, and what the comment mentions checks out — when defining the script property for a Core Block, JS is loaded regardless of the blocks presence in the post.
As the changes in this PR are meant to affect only Core Blocks, it seems like the best course of action is still loading these files through the block's render_callback; this ensures that the JavaScript is loaded only if the block enqueuing it is present.
There was a problem hiding this comment.
I compared both approaches, and what the comment mentions checks out — when defining the script property for a Core Block, JS is loaded regardless of the blocks presence in the post.
Do you mean that you confirmed with tests that the script defined with script in block.json enqueue on the front-end even when it's not rendered? I'm sure it worked properly at least for CSS with the changes that @aristath landed in #25220. Ah, I see now, it only applies to FSE themes or themes that opt-in for the behavior with load_separate_block_styles. By the way, we should change the name of the filter before backporting it to the WordPress core to cover the scripts part as well.
webpack.config.js
Outdated
| @@ -93,6 +94,13 @@ module.exports = { | |||
| entry: gutenbergPackages.reduce( ( memo, packageName ) => { | |||
| const name = camelCaseDash( packageName ); | |||
| memo[ name ] = `./packages/${ packageName }`; | |||
|
|
|||
| const modalsPath = `${ memo[ name ] }/src/navigation/modals`; | |||
There was a problem hiding this comment.
Maybe we should do something a bit more generic. Basically add packages/block-library/src/*/frontend.js as entry points, so that any block that has a "frontend.js" on its folder get that frontend script automatically registered and enqueued properly.
There was a problem hiding this comment.
Agreed, that is what I was thinking; creating a standard directory, or file, that if present will be picked up by webpack and output to build/ so that we can use it later.
I'll add that generic behavior here, so that we can see it working.
There was a problem hiding this comment.
It would be important to come up with a good pattern here as we will have to promote it in official docs when adding support to @wordpress/scripts. This is how it's handled for CSS at the moment:
https://github.com/WordPress/gutenberg/tree/trunk/packages/scripts#using-css
index.css– all imported CSS files are bundled into one chunk named after the entry point, which defaults to index.js, and thus the file created becomes index.css. This is for styles used only in the editor.
style-index.css– imported style.css file(s) (applies to SASS and SCSS extensions) get bundled into one style-index.css file that is meant to be used both on the front-end and in the editor.
There is also index.js in the build folder, so it feels like in @wordpress/scripts it should be script-index.js.
Although, maybe we don't need to care about it for core blocks. Yes, I guess it's fine to pick whatever makes sense. It probably would be better to go with script.js if we were to continue using script from register_block_type.
There was a problem hiding this comment.
Maybe we should do something a bit more generic. Basically add
packages/block-library/src/*/frontend.jsas entry points, so that any block that has a "frontend.js" on its folder get that frontend script automatically registered and enqueued properly.
Added something like that in 828e502
Right now it:
- Looks for
script.jsfiles within all blocks in the block-library package. - Builds that file and puts it in
./build/block-library/blocks/<block-name>/script.js, and - The
block.jsonfile at that location takes care of pulling that JS everywhere; editor and frontend.
vcanales
force-pushed
the
block-frontend-js-poc
branch
from
a10c0fc
to
2144245
Compare
|
It's still not clear or me why this functionality would be only loaded on the frontend? What about the preview mode in the editor, shouldn't it also be included there so you could check the experience? I think it's particularly important for the full site editing mode where there isn't an easy way to preview your changes outside of the editor. |
Good point. I think for the specific task at hand, a hamburger menu, we have imagined an editing interface that probably doesn't require the modal interface, but rather creating a facsimile that works on-select. However in the name of making things generic, it does make sense for the script to load in both, even if we end up not using it in the editor. |
As it is right now, this loads a |
|
I strongly request making a 'standardized' 'right' way to enqueue JS needed in the front end of the blocks so that they can only enqueue the JS if they are existing on the page and adding that information into the WP Block Editor documentation Also, it would be super helpful if the front end JS had access to the attributes of the block itself. The thought process for developers accustomed to working in a more component based way (like React itself and thinking in "state") would appreciate having that access - even if it was a way to sort of mock up an initial state of the block on the front end and use that information to react to events. Take for instance a button which pops up a form. This is a great example of a common use case which could greatly benefit from
Thank you, |
|
Just wanted to bring this comment here #29606 (comment) that suggests that lazy loading frontend JS is already in place (something I didn't know about) |
|
@youknowriad, see my comment: It is in place, but only for FSE themes or themes that opt-in for the behavior with |
Yeah, to be more specific this is the code that uses that filter to change the behavior: Lines 105 to 119 in da8555d Since this affects both styles & scripts I submitted a new PR in #29703 to rename it from |
There was a problem hiding this comment.
Nice progress so far! I did some quick manual testing for the following cases and verified that the script only loads when the nav block is added.
| No Navigation Block | One in Post | Two in Post | Two in Post + One in Header |
|---|---|---|---|
 |
 |
 |
 |
@vcanales do you mind adding more script.js files for more blocks for the PoC? I think it'd be helpful to see what bundles get generated for different block combinations.
Also tagging @sgomes @josephscott in case y'all had thoughts on loading JS on the frontend for core Gutenberg blocks.
Thank you for looping me in, @gwwar! 👍 I don't know enough about all the constraints to recommend a particular solution, but it looks to me that the principles to follow would be:
In general, all of those criteria seem to be fulfilled by this solution. Things like shared dependencies are also taken care of by this approach, assuming that the The only issue I see with this approach is that it involves tying into the Gutenberg build system, which would essentially make this functionality available to core blocks only, as I understand it. If loading JS for a block proves to be a common need (which so far doesn't seem to be the case), then it may be a good idea to bake a standard way of doing this into the Gutenberg API. Once that's present, it could be leveraged by external blocks, but also perhaps used to lazily load any libraries that might only be in use in a core block or two at the moment? Not sure if that's currently the case for any core blocks. |
That is correct; right now it's only targeting Core Blocks.
I believe plugin authors could also find this useful. Right now their only option is manually adding the JavaScript through the .php file within the block, where people are also running into the issue of JS being loaded everywhere instead of when the block is present when following the instructions found on several sources. Here are some examples of this. Not only it's on them to find answers, they also have to build these files separately from the build process of the plugin, as there isn't a way to hook their plugin to our build process. This PoC only looks within our Block Library to build these Frontend JS files, but by moving this from our main webpack config file into |
vcanales
changed the title
|
We discussed this PR during the weekly WordPress Core JS chat (link requires registration at https://make.wordpress.org/chat/): https://wordpress.slack.com/archives/C5UNMSU4R/p1615908666037500 I wanted to share my thoughts on how I think we can make sure it can land pretty soon. First of all, we already discussed that
This PR shows us that we might also need to have a way to define a script handle that loads only on the front-end. Let's say we want to use React to render some components. In that case, we would need to call I'm aware it might take some time to land changes in the WordPress core, so that's why there needs to be a plan for the Gutenberg plugin. The short term solution can look as follows:
|
Can't we use the "render_block" hook and just avoid any custom code in the block itself? |
This might be a better option here that covers more scenarios (registering from |
Sure, that's more or less the same. We only need to make sure we backport the filter to the WordPress core. Well, I think we will have to update the build processing in the core regardless, to account for new JS files. Whatever works best here. |
vcanales
force-pushed
the
block-frontend-js-poc
branch
from
f4b0d01
to
a65b745
Compare
vcanales
force-pushed
the
block-frontend-js-poc
branch
from
eafbd5e
to
6f5d841
Compare
In my manual testing, I've noticed that loading scripts from block.json works, but it also loads the script even when the block is not present. With the following in the block.json fie of the Navigation Block: {
"style": "wp-block-navigation",
"script": "file:./frontend.js"
}And this in console.log( 'This was loaded from frontend.js in the navigation block' );I see this when loading a post that doesn't have a Navigation bock:
This feels like a bug, because the asset should be pulled on render, and not every time. I've got to admit though, that I am not sure if this is the only place where files defined through block.json/ |
|
I can share a PR with you where the changes proposed here are used, and are pretty much a pre-requisite: In $script_path = __DIR__ . '/navigation/frontend.js';
if ( file_exists( $script_path ) ) {
wp_enqueue_script(
'core_block_navigation_load_frontend_scripts',
plugins_url( 'frontend.js', $script_path ),
array(),
false,
true
);
}I have also removed usage examples from this PR, as I feel they were confusing the scope of what we're trying to accomplish here. I believe it's viable to leave autoloading for a subsequent effort. For instance, we have to figure out why files defined through |
|
Closing in favor of #30341 |
In order to have an accessible Mobile Responsive Navigation Block, we might have to load some JavaScript in the frontend — bringing in a library such as micromodals, or building something ourselves — to implement keyboard navigation of the Dropdown Menu.
We can load JS in the frontend when the Block is rendered, calling
wp_enqueue_scriptas a part of therender_callbackfunction, but in order to load that JS file, it has to be created somewhere within thebuild/directory.We can’t use the existing
index.jsfile from the block-library package because:To create this file separately, I came up with adding it as an entry point in webpack, so that it would be created as a part of the build process as a standalone file that can be pulled from a place within the plugins URL.
This is a proof of concept, so the path for the file containing the JS for the Navigation Block is hardcoded. There is room to create a standard directory or file, from which we could load this sort of arbitrary JS for any core block that would need it.
There's also the alternative of loading this sort of JavaScript through the script-loader, but this would detach it from the Gutenberg Plugin.
I realize JS is being avoided in the frontend purposefully, but as far as I can tell the alternative I know to create Dropdown using only HTML and CSS can't be made accessible without JS. If there are other accessible JS-free alternatives, that would also be very helpful!
Types of changes
Checklist: