— Roadmap Card
Description
From what I understand, Styled Components is used in Frontity in order to codesplit critical CSS on a per component basis.
But the vast majority of content produced via a Wordpress backend will not be determined by the frontity app but by the content within the post itself.
Most Frontity themes have not yet hit this problem because they’re primarily focused on simple text hierarchies. But the Gutenberg editor introduces much much more possibilities. It is pretty conceivable that Gutenberg editor can eventually be used to essentially build entire pages. Lots and lots of custom gutenberg components and you have lots and lots of CSS styling that gets loaded on every single page and post regardless of if that particular component actually appears in that page or post.
The total number of lines I use to style the non post-content components in my WIP theme is maybe 20 or 40 lines at most. While the components which are possibly contained in a post’s content are several hundred easily.
This should be fixed. I don’t know how it, perhaps it will take a Wordpress plugin exposing a list of all components used in a post or something of that sort, and then having Frontity logic for conditionally loading styled components based on the expected post content or something like that?
Thanks for your comments @thedonquixotic! I totally agree it would be a great functionality 
If I understood it correctly, you’d like to load just the css necessary for each post right?
We are talking about at this topic. As Luis mentions, we thought of creating a first version of the Gutenberg CSS package to import all the css into <Global />, and start working on a new version where we can use processors to modify emotion css prop. This way, only the css needed for each post would be loaded.
Could you confirm if that’s what you are asking for? If so, I think the best option would be to continue the conversation here, that way users can keep track of the whole process.
1 Like
Hey Santos,
Yeah, that thread about the Gutenberg CSS package sorta addresses this feature request. The ability to use a processor to modify selective what critical CSS gets loaded on a per post basis might address this functionality but it doesn’t directly state that in Luis’s post. Furthermore, I believe Luis’ intention with the Gutenberg CSS package is to sync the default stylings of Gutenberg components defined in Wordpress, while this is really more about specifically code splitting styling for a theme based on the contents of a post (which would perhaps include but could also exceeds the definitions of the default Gutenberg component styles espc if you’re talking about adding any custom components to your wordpress installation. )
Personally I would look at this feature request as a distinct feature that might be covered by a particular package being worked on by Luis but isn’t necessarily. It’s unclear to me to what degree it actually does or does not.
Hi @thedonquixotic
Okay, we can keep this other discussion as a different feature. But I’m not sure if I understood you correctly. I’ve updated the opening post of Gutenberg CSS discussion to clarify what’s expected to be solved with this, and that way we can do something similar to write down here what it isn’t included.
If I understood you correctly, loading just the Gutenberg css needed for a specific post/page is not enough for you right? What you miss is the fact that it wouldn’t support the custom blocks you build?
Yes the updated description mostly covers what needs to be done. The only caveat is the custom block stuff.
Yes, that is essentially correct. In my understanding the proposed solution is to automatically take the styling used by default wordpress blocks and then load and apply that css based on what components are contained. This is fine, but what if you don’t want your blocks using default styles?
This is relevant particularly with how Wordpress default CSS works in how it contains text. It puts all elements in a single “content” element div with a max width, while other themes (such as my frontity theme) maintains the width of elements using padding and margin, which is necessary if you want to have images that break from a strict column grid.
Furthermore, as mentioned before, this is relevant for when you want to use components that are non default gutenberg components. So there needs to be a way to write styles that get processed and attached to specific components so that when they load those specific components they are able to do and still get the CSS code splitting performance advantages.
Okay, I have renamed this to “Import Gutenberg Custom Blocks CSS”. What do you think?
Anyway, we have to keep in mind that the frontend (theme) is mostly managed from the Frontity side, so the styles getting from WordPress should be minimal. Sometimes, it’s a better practice to just add a class to the <div> or attribute you want to modify, and add some css or logic from the Frontity side using @frontity/html2react processors. We’ve used this approach in other projects and it’s simple and flexible. You can also pass general classes not supported by default Guteneberg block editor like has-shadow for example.
1 Like
Let’s also keep an eye on the Global Styles proposal for Gutenberg:
1 Like
I don’t think this really addresses the issues. The issue is not importing the Gutenerg custom Block CSS. Someone might add a custom block to their WP via a plugin, but they don’t necessarily want their styling determined by the plugin. Maybe someone people will want that CSS auto imported to their Frontity project, but for me, I really would prefer to write my own styles and just let the Gutenberg component add html to the content, that then I can write my own styles for in the Frontity frontend.
The difficulty here is NOT styling these custom components, it’s identifying if they’re on the page or not so that Frontity can determine whether it needs to load a bunch of codesplit custom css or not.
Oh, then I think you can achieve that using @frontity/html2react package. You can create your own processors, parse your content with html2react, and if any element match the conditions set in your processors, it applies the logic you define. For example, you could create a processor similar to this one:
import { css } from "frontity";
export const customElement = {
name: "custom-element",
test: ({ node }) =>
node.props.className.split(" ").includes("custom-element"),
processor: ({ node, state }) => {
node.props.css = css`
${node.props.css}
background: blue;
color: black;
//All your styles
`;
return node;
},
};
This way, if the html2react package finds an element with the class custom-element it will add that css.