block.json: Add viewStyle for frontend-only block styles

[gaambo]

• Part of #41236.

What problem does this address?

At the moment block.json allows adding styles and editorStyles - where the assets of style are loaded in the editor and in the frontend. There's no way to add styles which are only added in the frontend. Not having this assumes, frontend styles can be used 1:1 in the editor. I've encountered many situations where that's just not true - it has gotten a lot better with the apiVersion: 2 blocks, but there are still many cases where I want to enqueue a style only in the frontend. Examples:

• Very complex blocks - where I will develop a very specific block editing experience in the editor with components and editor styles and want to load the "real" styles for the (dynamically) rendered block only in the frontend.
• JavaScript-heavy frontend - the most basic example being slider. I will have a lot of CSS which only styles the JS-initialized version of the block and they just don't need to be loaded in the editor.
• There are cases where the frontend styles are just not used in the editor (and I know that while developing), so it's a performance slow-down if you have many such blocks. But there are also cases where the frontend styles may just "destroy" the editing experience of a block because they just don't work in that context.

What is your proposed solution?

For scripts there's already script, viewScript and editorScript. #33542 also brought parity to those so all of those support the same values (file paths, asset handles, one or multiple). Therefore I propose a viewStyle property which works just like the viewScript property but for styles. The style property should stay the way it is now (load in frontend + editor). See #33542 and #41236 for prior discussion.

[gaambo]

I can try and draft a PR in the next few days for this.

[gaambo]

@gziolo here's the new issue for viewStyles.

[chimok]

I do personally dislike the idea of of viewStyle. It can make things very complicated. It's usually enough to get the same results with overwrite or reset CSS in editorStyle, the only disadvantage we have then, slightly unnecessary loaded CSS inside the editor.

@gaambo Have you tried to use conditional dynamic import in your viewScript with the use case you described (JavaScript-heavy frontend)? With webpack it should work with CSS. https://webpack.js.org/guides/code-splitting/#dynamic-imports

[gaambo]

@chimok We don't use webpack and bundle our CSS separately from JS. Also - maybe I was not clear there - it's not about JavaScript-heavy frontends per se, but single blocks that may have much frontend JavaScript (sliders, accordions, interactive things, etc.).

I understand, that in many situations, just using editorStyle to overwrite/reset CSS may be enough for simple blocks. But overwriting CSS can be hard sometimes, and I always find writing "fresh" CSS better/easier that overwriting existing CSS for the editing context.

Since these three ways already exist for scripts, I don't see any disadvantage for providing these also for styles. It doesn't force block developers to use them. The preferred way (and referenced in docs, on learn and in tutorials) may still be to put most of the common stuff in a common style for frontend + backend. But it allows developers of more complex blocks to use it. Maybe you can explain your reasons for disliking this solution more clearly, so I can understand.

[chimok]

@gaambo Because I think if someone will use all 3 together (which is in theorie possible) the results may be unexpected? For that reason I like simple configuration that can't break. Oh, and try using @wordpress/wp-scripts, without a bundler Gutenberg isn't fun and you may load more unneeded assets.

[gaambo]

@chimok I don't really see how it's more complicated than scripts, viewScripts and editorScripts. Also, I don't think the results can be unexpected: There's one property for frontend+editor, one for editor only, one for frontend only. That seems really clear to me. In most cases, developers will get through with just a style property, but having options would be good, regardless of bundler/build-system. If only for the sake of parity with the scripts properties.

@gziolo Sorry, I somehow thought I already had written this somewhere: It seems only the schema of block.json and documentation is in the Gutenberg repository. The code to load those assets is in core: here and here. So should I open a trac ticket for that?

[gziolo]

It seems only the schema of block.json and documentation is in the Gutenberg repository. The code to load those assets is in core: here and here. So should I open a trac ticket for that?

That's a good point. Most of the code lives in WordPress Core now so it makes sense to open a ticket in Trac. On the Gutenberg side, we will mostly have to update the documentation and extend the schema once the implementation lands in core 👍🏻

[gaambo]

Added trac ticket here: https://core.trac.wordpress.org/ticket/59673

[gziolo]

I have just committed core changes with https://github.com/WordPress/wordpress-develop/commit/1a5ff3fc6dbe45376b54335028d8e9b19da93244. Let's finish the Gutenberg changes now. Awesome work @gaambo 💯

[gziolo]

The documentation changes are in place in Gutenberg with https://github.com/WordPress/gutenberg/pull/55492.

It would be nice to replicate something similar to what @sirreal did in https://github.com/WordPress/gutenberg/pull/57437 for viewModule, and bring the same experience for viewStyle when using the Gutenberg plugin with WordPress 6.3 and 6.4. It isn't mandatory as none of the core blocks uses viewStyle, but some folks might get surprised.

The other thing we were discussing with @gaambo in the WordPress Trac ticket was creating a test plugin with a custom block that uses viewStyle in the block.json file and activating it in a new e2e test case to validate whether the functionality works as expected.

[gaambo]

Regarding core 6.3/6.4 back-compat: I'm sorry, I don't think I'll be able to do this in the following weeks, so if anybody wants to take over, feel free. Otherwise, I'll see if I can make it work mid-february.

[gziolo]

Regarding core 6.3/6.4 back-compat: I'm sorry, I don't think I'll be able to do this in the following weeks, so if anybody wants to take over, feel free. Otherwise, I'll see if I can make it work mid-february.

That sounds good. Let's see if anyone picks it up in the meantime 👍🏻

[gaambo]

@gziolo I've added a PR for pre 6.5 compat for viewStyles here: https://github.com/WordPress/gutenberg/pull/59322

[gziolo]

@gziolo I've added a PR for pre 6.5 compat for viewStyles here: #59322

Excellent, thank you!

[gaambo]

@gziolo Should we close this issue (once the compat PR is merged) and should I draft up some text for a devnote?

Edit: Ok, just saw it in the miscellaneous changes:

viewStyle property has been added to block.json. This change brings block styles in parity with block scripts. (59673)

[gziolo]

Yes, I have just approved #59322 with the backport from WP core. The dev note covering this new feature was published, too. Once the PR lands, this issue will get automatically closed 🎉

[colorful-tones]

How does one get the "viewStyle": "file:./view.css" to work in their custom block? I'm using "@wordpress/scripts": "^27.7.0" and "@wordpress/interactivity": "^5.5.0". Everything works fine with my block and I'm even seeing build/view.asset.php, build/view.js, and build/view.js.map being generated. However, nothing is hooked up on the final frontend view. Am I supposed to @import the view.css somehow? @gaambo @gziolo

[gaambo]

How does one get the "viewStyle": "file:./view.css" to work in their custom block? I'm using "@wordpress/scripts": "^27.7.0" and "@wordpress/interactivity": "^5.5.0". Everything works fine with my block and I'm even seeing build/view.asset.php, build/view.js, and build/view.js.map being generated. However, nothing is hooked up on the final frontend view. Am I supposed to @import the view.css somehow? @gaambo @gziolo

You can find a test block here: https://github.com/gaambo/test-block-viewStyle In this case, I'm importing the view.scss in the view.js (also because it's a scss file and needs to be built).

block.json https://github.com/gaambo/test-block-viewStyle/blob/9075c803204584f2aa97e7714f081270b0995b7e/src/block.json#L15-L18

view.js https://github.com/gaambo/test-block-viewStyle/blob/9075c803204584f2aa97e7714f081270b0995b7e/src/view.js#L23

AFAIK the scripts package does not build any style-files that are not imported in a JS file (since I couldn't find any place where that happens in the main webpack config). So in my understanding this is the same for editorStyle, style and viewStyle. You need to import it in a .js file - since these are the entry points for the build process and build/copy/rename the files accordingly.

Should we update any documentation (eg this) to make that more clear?

[colorful-tones]

I'm importing the view.scss in the view.js

Ok, this makes sense. Thanks for clarifying. I was missing the obvious.

Should we update any documentation (eg this) to make that more clear?

I think a general note that the import needs to be there could save somebody some frustration.

I'll look to open a PR later today to address it. Thanks @gaambo