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

[gaambo]

• Part of Block API #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