Episode Transcript
[00:00:02] Speaker A: Welcome back, Ian.
[00:00:08] Speaker B: Well, hey, thanks for having me back, man. It's a pleasure.
[00:00:11] Speaker A: Yeah, well, yeah, it's a pleasure for me as well. We had. You've been on the Within WordPress podcast before. We spoke at length about blocks in the broader sense of the words. We talked about the block editor, we talked about the site editor.
And.
Yeah. So the reason I invited you to come back is not only were people very happy to hear you and I talk about that you recently were part of a release of a product, and I'll let you introduce all of that yourself where I think it's fair to say you took the block editor a step further than it's been taken so far.
And I think this is something that people need to hear. I think this is something that people need to learn about, understand what the challenges are and how we can push the envelope with what we have as our default editor for both the site and content. So, yeah, what can you share about? First of all, for those who haven't heard you before, your name, your role and what it is that you delivered built.
[00:01:26] Speaker B: All right, lots of stuff. Lots of. Lots of questions to touch on. We'll start from the top. My name is Ian Svoboda and I am currently a developer on the Generate Press team. I was working very closely with Tom, the owner of the company, original creator software, you know, on this 2.0 release, which builds upon the foundation of a few things before, like where we. We introduced this concept of global styles and classes. So you can use like a class first approach to styling your block components inside the editor, which was originally just limited to those classes that you'd create so you could go in and, you know, create some class, name whatever you want and style it just so. All that kind of jazz. But in this next release, we were trying to refresh the blocks, take the learnings from the 1.0 version and make them into something newer and more adaptable, something that had less technical debt. And that was another interesting thing that I would want to, I would want to touch on is like, what were some of those, what were some of those technical debt pieces? Right? Because a lot of the, A lot of the motivation behind this release was to try to simplify the overall structure, make it so that more things were compatible with each other. Instead of making a bunch of very specific blocks, we were able to make several blocks from effectively one and make them as variations of other blocks. Like the button block, for instance, is a variation of the text block. There's the element block, there's certain Other very specific blocks that are created, but they all are very much focused on the things they should be concerned with. And they're very pluggable and adaptable in ways that they were not before. Like in the past. Right. When you'd be. If you were going to be applying local styles to a block, you'd have the control and it sets an attribute on the block, kind of like a regular core one would. But the moment you start getting into doing things like our styles builder does, where it has a ton of CSS properties, nested selectors, media queries, all these things, making an attribute for all that is not practical on a number of levels, but also it becomes a validation nightmare. You're talking about writing block migrations now. You want to add new CSS properties, you're having to change, like actual data. It's a whole. It's a whole mess. And it became very clear that that was not the approach that we need to take. And so our approach is a little different now, where we have a styles object effectively on each one of these blocks, and it just contains the style definitions in the same format that you'd find them on the global styles. So it's basically a representation of CSS and things. It's used to output actual css, but it's all inside just an object. So in the block JSON, we're just registering an object called Styles. We're not putting every single possible key that might be on there or really any defaults at all. And it allows us to be super flexible with that. We can define it just about however we need. And being able to bring that styles object concept into the local blocks, I think was one of the biggest linchpin things for, like, tying all of this together.
[00:04:42] Speaker A: Yeah, right.
[00:04:42] Speaker B: Because like, once you, once you can do that, it opens up all these other opportunities and, and possibilities. So that was a really big one.
[00:04:53] Speaker A: Yeah, so. So you, you, you dove right into answering, already quite, quite in depth. But.
So for those who don't know, what does the solution actually do?
[00:05:07] Speaker B: Oh, that is a great question. I should have started with that.
[00:05:12] Speaker A: You can do a lot in post Edit.
[00:05:15] Speaker B: Absolutely. The magic of Hollywood. So normally when you're dealing with a block and you have these controls in the side, it's based on whatever the block supports. So it could be any number of possible choices, but it doesn't ever represent the full gamut or even close to the full gamut of the choices you have available in css. Things like absolute positioning or just setting, like grid template columns on Stuff, Anything Breakpoint specific.
There is none of that. And so this global style system was our way of effectively bringing a static CSS engine into the editor. So you can have it. You can just use a UI to input these things nice and easy. And it outputs CSS and a class just like as if you were having a developer write it for you or you, the developer writing it yourself. And we wanted to bring that same flexibility to the local blocks. I mean, if nothing else, because it's a much better experience. You have a lot more control, a lot more choice. But then also it makes everything else kind of work the same. So instead of having this fragmented, like way that you style things, we're kind of using the same mechanism just in a few different places.
[00:06:28] Speaker A: Yeah.
[00:06:29] Speaker B: So it enables us to have like, you have control over the output of all this stuff like you've never had before. A lot of control over the markup as well as the styles, all kinds of things.
[00:06:40] Speaker A: So that sounds like going from version one to version two was more than an architectural thing, it was an entirely rethink thing.
[00:06:53] Speaker B: Oh, yes. And that is part of the reason why the whole thing ended up taking a little bit longer than we'd originally planned. We've been having to go through a longer beta and alpha period because we're just rigorously testing all this stuff and it's really coming together nicely. Gotten a lot of really great community feedback and feedback from members of our team to make this thing about as reasonably bulletproof as we can. And there's always more you can do. But yeah, yeah, it's, it's, it's definitely more than just a little bit different. I mean, it doesn't mean that if you had those older blocks and you upgrade that your entire site's going to break. In that case, it's actually still going to show you.
[00:07:32] Speaker A: That's an interesting question. Right, so there were. If. If.
When was the first version released? What version of the block editor did we have? Do. Do how many years?
[00:07:43] Speaker B: That's a great, That's a great. That's a fantastic question. I probably should have a more tidy answer to four or five years ago, something like that. I'm gonna try to. I'm gonna try to see if I can tell you real quick. But yeah, it's been, it's been a minute for sure.
I want to say. What's this first one? Pulling it up down here now?
Right about. Yeah, August 30, 2022. So about two and a half years.
[00:08:12] Speaker A: Ago seemed longer in my head, but so my logic is that if you're building something, you know, whatever is available to you at a certain point, and you have to rely on the options you have inside that solution, you're going to find yourself, upon revisiting the particular solutions as a base or the block editor, you're going to find yourself thinking, oh, now I have these options that would have made my work a lot easier. Or what if. Oh, what if this option now allows me to do xyz? You know, there's a whole sort of like a trigger that happens when new stuff is available to you. You see that happening in WordPress. You see it, but you see it on iOS and Android. Like, you know, there's new features. Oh, now I can make my app even do all these things. Extra. At what point did you go, ah, that's the missing key. This is what I needed now. Now we can start thinking about 2.0.
[00:09:19] Speaker B: Well, I think that. I think that the, the real genesis of that was something that Tom came up with, right, because he was looking at the container and, and some of these other blocks, and the container was a very multipurpose block. So it had all this kind of edge Casey logic for the different ways it might be used. And we were trying to figure out a way that we could refactor the query loop originally so that it didn't have a bunch of random markup that it would insert to enforce the grid columns. And you could just use like CSS grid on it directly and it would kind of work more like how you might expect it to work based on how it looks, versus having a bunch of like hacky markup stuff to make it go. And so he had this idea for trying to create a more streamlined set of blocks that would be a little more pluggable, a lot less opinionated. So that way you wouldn't have that sort of dependency and these, this weird maintenance nightmare that would accompany making changes to those things.
And initially the initial approach was to try to make everything out of like one or two blocks. And that is very much not viable for a number of very important reasons. The biggest one of which is that a block variation is not treated the same as a regular block in terms of things like the inserter. So if you want to limit what's in the inserter, you can't really do that with variations the way you can with regular blocks.
There's all these kind of little edge cases where trying to use a variation instead of an actual block, you run into problems where you don't have as much control or you don't have the same choices available. Right. And so it quickly turned into more trouble than it was worth. But we realized that, you know, there was still kind of something to it. It's just we, we had. And I think there's an important lesson in this where we said, well, we don't have to do everyone that way. We can just do most of them, the main things that way, at least as much as we can. And then, you know, we make a no results block, we make a list item block or loop item block, rather stuff like that. So I think when you're developing for a solution like WordPress, the WordPress block editor, which is not exactly opinionated fully, but also not fully extensible, it kind of tries to be a little bit of both. Depending on which part you ask, you might say you have to be prepared to like deviate from the plan, you know, wherever you're getting friction. So like, if you're saying, well, we're going to do all of it this way, but in these couple areas over here, it's actually really obnoxious and really cumbersome to do it, you should just do it a different way. Like be, be willing to be flexible so that you're not having to like fight the editor and try to do all this hacky stuff to make a variation work the same way as regular when the inserter some. Sometimes stuff like that is just. It's not a practical battle to fight, especially when you're trying to ship something. If you have endless tinker time, well then sure, you know, maybe. But in our case, you know, we wanted to try to focus on meaningful improvements, trying not to like just bike shed on things or like endlessly go around the loop of like what, no pun intended, literally, what could we, what could we do here? And so we just found it's way more reliable when we do this, that or the other. And there's, there's several other examples of such things I could get into.
[00:12:39] Speaker A: But, but yeah, so for anyone out there looking to extend.
So you know, obviously the, the, the generate blocks has a whole array of extra blocks, like proper variations.
I can imagine there's a lot of developers out there looking at the same problem in essence, right, Going like, okay, I have this requirement.
It means I need to build a block. I may look at building a custom blog from scratch, or I may even use ACF as a base or whatever, but at some, some point you find yourself hitting limitations. Now when those limitations start becoming insurmount, insurmountable Insurmountable. What is the word?
[00:13:33] Speaker B: Insurmountable. You got it.
[00:13:34] Speaker A: Insurmountable. At what point do you decide to put in the effort to actually create something structurally differently based as you have done in your particular case? Obviously you build a suit, a suite that's supposed to work for everybody and all different types of scenarios. So maybe you have some extra stuff that you need to take into your decision tree. What kind of advice would you give for somebody who is, you know, looking at that type of oh crap, I need to build something, I have no clue how to approach it.
[00:14:10] Speaker B: Well, as far as for how do you get started? Usually a good place to start is find something that you already know. If you, if you can find something similar to what you want and say what did this person do? And that doesn't mean copy them, it just means actually look at the reason like the why they did things a certain way. Oh, they used this attribute or that or they, they just did it all with children or what have you. But I, I think that there, there's definitely a danger in feeling like you need to abstract too soon, right? Like sometimes it feels man, I really should just build a block that does all this stuff, right? Like it's a multi purpose block and it can be any element, kind of like our element block or something. It's like sure, you could do that but for a client work right, where you're not building a toolkit for anybody to build anything with that type of thing is almost always never going to be worth as much time as it'll take you to create it. Like it's nice and it's handy, but you could have probably just hard coded it in the three or four blocks that are actually going to use this thing in a fraction of the time changing it is not going to be as big of a deal either because they're so similar. It's just, it's a problem of scale, right? Like you don't product. When you're building for a product like a plugin that you sell to other people versus like building something for a client like a more bespoke solution or what have you. Those are very different requirements requirements. So it's important to not they are.
[00:15:37] Speaker A: But there's a, the, the point. I was, I was, you know, curious about your take on it. There comes a point where you have to make a decision whether that's from a client's perspective or something you need to ship to the general public. Sure, that's a determining factor, but there are also technical choices. You need to make. Obviously hard coded versus dynamic is a huge one, but we're just going to assume everything needs to be dynamic anyway.
What kind of things are you running into? Like, what would be like, okay, when this happens, you have to do that sort of.
[00:16:16] Speaker B: Haas, I have a great example that came up, which we can talk a little bit more about the whole way that we do this, but we have this really neat meta handler that this is something I actually created in the process of making something else that's for our dynamic tag system, right? So you can use that to fetch post meta and it's smart enough to where if you have that post meta, it's like an object, like an ACF image field that returns like the image array. You can pull keys and nested keys and all kinds of stuff off of that using our dynamic tag system or this meta handler, right?
[00:16:52] Speaker A: Yep.
[00:16:53] Speaker B: So that allowed us to do a lot of stuff. Like if you're making a query loop of any sort, whether it's a post query or whatever, we're able to expose the object that's being looped over, right? Then in our loop item tag, which you can then access with keys, right? Which is awesome because like, say if you want to get the post status off the post object, and we don't have a tag for that because who often uses that, but there's things that could be on there that you might want. So you. So you just say, I want to go post underscore status. And that's my key. So when we first did this, we ran into an issue right away because we were using a rest endpoint, right, which returned all of the post keys, like on the, on the post that it returned. They weren't the same as the actual WP post object on the front end. So you'd type, say, post status. It wouldn't preview anything, but then if you saved it and looked on the front end, it would be correct. So we had a scenario then where we had certain fields that had different names because the REST API maps them differently, as many people yourself probably know, right? So at this point, we were at a crossroads of we either have to come up with an adapter that maps the rest fields that we have zero control over whatsoever to the actual ones that are used on the front end and then make all that work, or we could just build an endpoint that actually returns the original stuff anyway, like the actual WP query, WP post object, and just use that. And so that's what we did because it gave us the ability to make it direct and straightforward for like a, a regular person. So they'd go in there and they'd see the regular keys, just like you'd expect to see. Just like if you looked on the docs, you'd see the same keys. Right? All that, but in a way you're bypassing.
[00:18:39] Speaker A: What's the core way of doing this currently?
[00:18:44] Speaker B: Because it made, I think in this case it made more sense to do that because like, we already have, you know, these.
We already have this way that we do WP query things where you can like filter the args and we do a little bit of light cleanup. But now, and this is another thing that we changed in 2.0, all of our arguments, like for the actual query block itself, they're all like the actual WP query arguments, name for name instead of aliases like they were before and things like that. And it's just, it's a lot simpler when you don't have to like map the names to different things, which can allow the data to get mismatched or all. There's, there's a lot of, there's a lot of complexity with that. But when it's an endpoint and we own the endpoint point and we're using a very reliable, absolutely not changing anytime soon structure of data that allows us to create a more certain experience for people, we can handle errors better and make the whole app more reliable. But that was a situation where we absolutely had to color outside the lines. I think there, because this is a.
[00:19:49] Speaker A: This is one of those examples that I was looking for, like, so.
Well, first of all, you have to wonder how the current implementation has this limitation where you find yourself, if you're looking. So in essence, what generate blocks does it extends, right? What the current functionality of the blocks and the block editor is.
And for those of you listening and you've never played with it yet, go and go and download and check out this solution because what you'll see is that there's a whole bunch of blocks and variations of blocks, existing blocks are just providing that more than a little bit of extra thought into it. Like, oh yeah, okay, great, now I can also do this. And oh, there's a variation to that. And like you said, one of my favorites is the query and all its variations available. Because if you look the default version, it's quite, quite limited to then have to force yourself to work around an existing implementation where you go, like, who, who. Okay, first of all, who decided this? Why are we deviating a standard? Because there is a Standard. If there's in. If they're in the endpoints, why not just use them as is?
Were there a lot of frustrations like that as you were plowing your way through?
[00:21:19] Speaker B: Well, there.
[00:21:20] Speaker A: There are, is my assumption. I don't know, maybe you enjoyed it.
[00:21:24] Speaker B: No, no, no. I mean, hey, don't get me wrong. I. I am very grateful to be able to work on this project. Let me. Let me take a second to get slightly mushy, because I'm serious. I really enjoy working on this product. I mean, if nothing else, it's a product that has a large, larger install base. So I feel like I'm doing something useful, something that helps people. But the. The community is just. They're really great. Like, they're honest. They're not gonna just never complain or never say anything. Couldn't be better. But people are just, like, helpful. They provide constructive thoughts and feedback. Everybody's always like, super appreciative of the work, and it really seems to be helpful to people. And I really. I really like being able to do that. I think that that's really important. So one. One kind of example of like a frustrating thing that we ran across, one of them is the silliest thing. I'll start with that just because it's hilarious. We have these things called style indicators. This was an idea that I had for anyone who's ever used the developer tools where you can right click on an element and say inspect element, and go to the computed styles tab and it shows you in css, like, what are all these things that I'm clicking on? And I was like, man, if we had that for the blocks, that'd be really nice because then you could like, see, like, where this local. If it's a local style or a global style, and where does it come from? And you could click right there to go edit it and stuff. And previously we had an initial version of these that was only on global styles, but now the system is available on everything. It can tell you if there's a global style applying to your local block or if this local block has a style that it inherits from another break pointer. All these. All these different sorts of things. So when you're changing breakpoints, the actual editor resizes and all that stuff. And currently we're still using the second ver, the API version 2, for the blocks. Soon everything's gonna be moved to v3, but for now, some of the old Legacy stuff's using V2. Any of the V1 blocks in use would also be V2 blocks, you know, all that stuff, right, Whatever.
So we had this weird issue where we would resize to a different breakpoint and the indicator dots would show up for the previous breakpoint.
The way those things work is they actually use a native browser mechanism to check the actual computed style on the HTML element at a given moment. And it does conversions for what's called a used value. Like if you have a font size, the browser always reports it as a pixel, even if it's something else. And so we check all that stuff. All that stuff. It's very. It's actually remarkably bulletproof. So I was naturally shocked when this was happening. I was like, what did I do wrong? What mistake did I make? Right? Tom and I are bashing our heads over this for like probably half a day, plus maybe, maybe, maybe a day and a half, at least. And then I thought about something. I was like, it almost seems like it's. It's just checking it too fast. So I was doing all these react things, you know, trying to get in there. And are we doing these renders, optimized things? Are we doing the callbacks, memorization, all that stuff? We go through all this, nothing. But then I was like, wait a minute, there's a transition that's applied to this iframe. I wonder if it's checking before the transition is done. And sure enough, that's exactly what was happening. You turn the transition effect off, bug disappears. It was just caused because of that very. And it was only happening sometimes because with all the stuff going in the editor and plus we're in like, you know, development mode or script debugs turned on, so it's unminified and. But even then it's still. It. It was. It would just sometimes report incorrectly. And so we had to, you know, do a few things around that. Sure. And I was like, are we sure we can't just disable.
I didn't do that. I wouldn't do that. But I thought about it after a minute because I was just like, good lord. Like, that was insane. But yeah, like, that sort of thing is a big one. The. The way that the editor, like you can't currently control the actual width of the iframe. Even if you are in full iframe, everything, even if you use the new slop fill to add like breakpoints into the device preview, you can't actually control the width of the iframe yet. I think that's kind of weird. I'm hoping that's something that is going to be better pretty soon. But yeah, that.
Yeah, the certain. It's. It's a lot of. It's just kind of inconsistent implementations of things is a big one or like some stuff isn't exposed publicly, it feels like it should be. Sorry.
[00:25:54] Speaker A: Inconsistent implementation from block to block. Because that's the. Some of the stuff that I certainly in the earlier days accounted quite a bit.
[00:26:02] Speaker B: Yeah. And then there's also just kind of like there's certain hooks that seem. May seem similar to one another that don't always quite work. Work the way that you expect things of that nature. It's. It's really weird. Like a really simple example that comes. Well, simple ish example that comes to mind is the Interactivity API. Right. We had in the new query loop we wanted to at least have feature parity to the. To the core version. Right. Which isn't exactly hard in terms of the arcs, but they had that new.
[00:26:31] Speaker A: Instance not played with the Interactivity API. Can you briefly touch on what it does? Because it's.
[00:26:38] Speaker B: Oh yeah, yeah.
[00:26:38] Speaker A: APIs. What is it, six, five, Something like that.
[00:26:44] Speaker B: Yeah, yeah, I'm getting right to that. So what we wanted to do is we wanted to build this thing that would allow you to do what's called instant pagination. So that way you, when you hit the next button, it like immediately loads the section, doesn't require a whole page refresh and everything. And so what the Interactivity API is supposed to be for. For is to allow you to kind of sprinkle in JavaScript logic in your blocks or on the page to, you know, do certain types of things like this, like dynamically fetching stuff when you click on a button or if you're. If. For people listening, if you're familiar to something like Alpine JS or maybe even htmx, it's kind of sort of similar to what those things do, at least in premise. Right. So it's like you.
[00:27:28] Speaker A: Alpine is the best comparison to the point you have to wonder why we didn't implement that.
[00:27:34] Speaker B: But that's a good question. I think it uses preact under the hood too, which is a notable difference compared to Alpha. I could be wrong about that specific part, but so, so again, like you. You'd think that like, oh, this will be perfect and the core query loop uses the Interactivity API to do this exact thing. And so I'm thinking, okay, this is fine, you know, we can just kind of look at what they're doing and adapt it as necessary to fit our model and whatever like we've done with other things. Before. But as I looked at it, it became very apparent that there was something different that they were doing that was not documented. Like, in terms of like, in WordPress scripts, they have this stuff on, like, if you want to use the API, you got to enable modules and do these, all these different steps. But there was something that was not explained anywhere that just didn't seem to be the case. And like, I later found out that, that they, like, if you want to conditionally include the interactivity API on the page based on like an attribute that's set, like say if somebody enables instant pagination, then include it. Otherwise leave the 12 kilobyte script for someone else, right? In order to do that, they had to actually extend their Babel and webpack configuration for that very specific thing to build it in a completely different way than the other shit. And in, in, in the Gutenberg Project, which is something then that if you wanted to do that yourself, you would have to effectively do the same thing in your own implementation of WordPress scripts, which honestly, seeing that just made me go, yeah, no, like that, that, like that was an example right there of where I said I could do that. But then I'm loading a 12 kilobyte asset to just do instant pagination on top of all of the very cumbersome setup work to make a customized webpack config just to build this one thing. And so instead we rolled our own solution. We didn't make an interactivity API one to one example, but I created this. It's essentially a prefetching router mechanism thing, and we're going to use it for the basis of future interactive components that I'm not at liberty to describe things that might do similar stuff to that.
We wrote our own thing, way smaller, easy to conditionally include, and it does all the same stuff. You hover over the page number or the next and it prefetches the page and then it grabs that portion and slots it in and it just works. All of our stuff uses something called event delegation for all the JavaScript nerds out there, which means that if you have like an accordion, say or something that's like has clicks or whatever, and you do this instant pagination stuff, it'll just work with all that because of the way that it all gets loaded onto the page, okay? On top of that, the instant pagination works with the custom query types like the post meta query 2 or the.
[00:30:35] Speaker A: Options query, which not only did you find a limitation in how the current version of you Know, just Core has it implemented. You found a way to work around it, make it more efficient and for it to be able to be used in many other contexts.
[00:30:53] Speaker B: Yeah, yeah, it. It turned out to be a huge slam dunk there. Right.
[00:30:58] Speaker A: Like this sounds like hella cool.
[00:31:01] Speaker B: Yeah, it was great. Oh, so much fun. And so now we're able to make a really. Because, you know, we're. We try to not ship a lot to the browser. We want this thing to be like as close to as if you hand did it yourself. Right. Because that's the browser.
[00:31:15] Speaker A: Why not ship it off the browser? Because in general, you could argue that whatever the browser is doing is pretty stable because it's the browser.
[00:31:22] Speaker B: Oh, no, I mean like adding extra scripts to the page. Sorry.
Stuff like that. Like, like, you know, adding styles or extra scripts, things that make the page load slower. Right. We want to be performance.
[00:31:33] Speaker A: The dependency in browsers and like, you don't want to rely on those that.
[00:31:37] Speaker B: Oh, no, totally. Yeah. There's. There's a. There's another performance thing that I think I was looking forward to sharing with you in particular. So we can, we can about that for a minute, but. In a second. But yeah, so we wanted to be really careful about that. And you know, 12 kilobytes, like, I don't. For people listening, 12 kilobytes is an awful lot to just do this very small thing that I was just talking about. So, yeah, we're talking about a fraction of the size. And so that's again, one of those situations where you go, well, I could use, use the core thing or it can make something that's like a fifth of the size or less and it's way simpler to implement and maintain. And so that ended up being the better decision for our customers, we think, you know, making that call there.
[00:32:19] Speaker A: I would agree.
[00:32:21] Speaker B: So the, One of the interesting things that we did though, on a performance level, and this is, this is actually kind of an interesting thing for anybody who's making plugins that kind of work with each other or designed to be installed with each other. Each other or whatever.
When I first came out of the project, all of the UI for the editor was kind of like, it wasn't really standardized. There wasn't a component library of sorts or anything like that. I mean, there was some, you know, reused components and things like that, but it was, it was kind of more just done as it was. You know, there was the first version of the product. When you're trying to ship something, you're usually not super Concerned about all those things and whatever. And, you know, that made a lot of sense at the time. But it's like as we're doing this other stuff and we're using these things in multiple places, you know, that was when I said, okay, well what could we do to maybe make these things more reusable? So we have a series of private NPM packages now for like our components for the Styles Builder and this other stuff. So we can take that stuff and just put it everywhere, which is great. All of our plugins are able to use the same set of packages, right? But what that means then is that there is the possibility that, say, Generate Press or Generate Blocks, Generate Blocks Pro, they might all be using a different version of the same thing, right? So if you get into a scenario where you have like, the class names are the same, but now we got the CSS in this one that's not the same as that one or so on, whatever, which one wins, and all these, and all these different considerations. And then furthermore, if you have something that's like a bigger package, like the Styles Builder, it has a few more, like, larger dependencies in it for certain things it needs to do. It has like post CSS in there, which we're probably actually going to be able to get rid of entirely soon. But anyway, yeah, like, it was kind of beefing up the size of all these blocks, right? Because all the blocks JS files would be a lot bigger. We're like, this is. Seems like we're shipping a lot to the page, you know, like, or at least into the editor. So the editor would, you know, still. We don't want that to be slow either, right. And so I had this idea where we basically implemented our own dependency extraction scheme in webpack. This is a really interesting thing I'm bringing up because I don't know if people know this, but when you're developing in the block editor of any sort, whether you're just like making blocks for clients or product or whatever, there's those like WordPress packages like at WordPress/ components or Block Editor and whatever, you don't actually have to include those inside your own project. If you're using WordPress scripts or something similar, what it does is it uses a custom plugin that they actually made called the webpack Dependency Extractor plugin, where it looks at some of these packages and based on the package's name, it externalizes the reference to that package. So like normally in webpack terms you'd have. For people who aren't familiar with this normally if you have like say a ja react react component and it's importing something from a given package, right? Webpack is going to go to your Node Modules folder and get the stuff out of that package and actually put it in the resulting bundle that it makes, right? So if you have a bunch files all doing this, they're all, they all have copies now of that in the. In their bundle, which for a bunch of blocks is kind of wasteful, right? So what WordPress does is they have this like, it's called WP. Like if you go to the console type WP, it's got that object and then it's got some of these other like basically a module for each of those packages in there. So webpack just says, hey, ask the browser for this globally available WP dot components thing. And that's what this module is. So it doesn't actually have to put that inside your own bundle.
So I basically stole the concept, ripped off the concept of that for our own stuff. So now when you load these things up, we just have like this one version that each thing uses. There's. There's a. One minor exception to that with the styles builder, but it's all done in such a way where it's using SAS modules and using this dependency extraction thing. So the end result is that all of our blocks that import these packages, they don't actually have to bring the package into their own bundle at all. All of the style, like the class names for all of these packages, they're all utilized using like a hashed module class name that changes based on the version of the package. So if two things are using a different version of the package, they will not even have the same class names. Thus they will never conflict and they will be completely separate. So it'll just work no matter what version of the plugins you have installed. But that was a fun technical challenge to solve. That took a little bit of iteration to get to the right answer. We did that wrong at first for sure.
[00:37:04] Speaker A: What I like about this is that you hear a lot of developers who need to extend the block editor in one way or another, people who have to jump into Project Gutenberg and all of the previous decision that lead up to this is why it is you hear a lot of complaining and some of that complaining is fair, I think, because there's decisions and choices that you gotta help me understand this one.
But. And I think you've mentioned one earlier, but there's also a lot of inspiration you can find in how to do things Smartly because it's, you know, people love to. What I'm trying to say is people love to complain, but there's brilliant solutions in how that block editor is working as well.
[00:37:50] Speaker B: Oh sure. Oh certainly, yeah. One thing that, you know, I'll take a quick moment. This isn't a 2.0 specific thing, but recently we released for GeneratePress Premium GP Premium a font library feature. Right. Which our customers been really user been really liking. Lots of great feedback on that. And so when we were doing that, this was another example of like having to color outside the lines a little bit, you know, and because at the very least, again, we wanted something that would be just as good as Core, but something that would work in our not full site editing block. Theme. Theme, right. Generate, press or whatever. So we, we more or less have a similar ui. Like you can, you can go to the Google Fonts tab on both of ours. It'll look very similar, but we have a couple of notable differences. We allow you to choose the subsets which as of a. The latest version you'll be able to choose multiple. That's coming out soon. You'll be able to choose multiple subsets in the ui. Right now you have to use a filter to choose more than one, but you can subset the fonts because by default when you use the WordPress font installer, at least at the time when we built this, it was pulling unsubsetted fonts. So it has the font in every language that that font supports, even if that language isn't being used on your website. So it makes the files kind of big and that kind of stuff. And Google's API for pulling font stuff is not exactly the most accommodating. I don't know if anyone has ever noticed this before, but that's a very.
[00:39:16] Speaker A: Friendly way of describing it.
[00:39:18] Speaker B: If you go to the API and you say, give me all your fonts, Mr. Google Mrs. Google whatever. They will give you every font including variable fonts as a non variable version. So even so inter say is a variable font. If you go to Google and you say give me enter, they'll give you the variable font. But if you use the API and the regular API and ask it for that, it will not give you the variable variable version. So you say, okay, well they have a variable version variable format option, API. Cool. You do that and you get a completely different set of data that is also not the same thing as what you would choose when you go to Google Fonts to pick this stuff. And what annoyed me the most Was if you go to Google and you say, give me Enter and it gives you the variable font and you put it on your site, that file is lean and mean. It's subsetted, it's got the Unicode range, it's modifier, it's optimized, and it's in the right form, W2. That's another thing. The variable fonts don't always return in W2 through the API. So it was, it was, it was this whole thing. I was like, man, that would be a lot simpler because when we WordPress, for those who don't know, they actually have a cached copy of all of the Google fonts that is on a CDN in a JSON file, and there's a bunch of preview SVGs that they come with. Bunch of really nice stuff, right? But you only are able to get the. The font file that is from that standard API response. That's what they have in there.
I had this unhinged idea where I was like, what if we just built the Google fonts URL like the regular CSS file would. Scraped it for the source values and downloaded those instead.
[00:40:56] Speaker A: And if we could.
[00:40:57] Speaker B: And just use the optimized versions instead. And Tom's like, you know, that actually could work. Yeah, I think that's. And so he. We did some research and there's this other plugin out there called OMFG Fonts or oh my God, fonts. OMG Fonts. So shout out to them for the inspiration this. And we, we looked and they're basically doing the exact same thing.
So we wrote our own. It was inspired by them, but it's like our own kind of version of this thing. Like we changed a bunch of stuff, but yeah, so it'll attempt to optimize those and then it can actually find the variable fonts version for you. And there's all kinds of other nifty little things that we let you do. Like you can set an alias for the font family, you can change the CSS variable that it outputs, you can set your font display, all that kind of jazz. But yeah, that was a scenario where we. It started off as a slightly unhinged idea, but it turned out to work really well. And Google doesn't give you a better way to do it.
[00:41:56] Speaker A: So I like those. I like those. Those. Those are hacky ways. By the way, the. The plugin you referenced, omgf, is from Dan van den Bergh, which is also a duchy.
Very cool plugin to check out for what it does. Optimizing fonts in many Ways, but definitely what, what, what I like about the.
So you and I chatted a little bit before we actually started recording. There's, there's like, there's like two, two, three different types of ways of looking at overcoming the issues, issues, challenges, whatever you want to call them, of building a product for the block editor.
I really like how, how generate blocks, slash generate press works. It's just a, it's a very simple, straightforward looking solution. I know it's not, obviously we're having this conversation. Anybody listening to it, it was not that technically inclined will go like, maybe this went a little bit over my head, which is fine. But my, my, my goal behind this was kind of like, you know, have you explain some of the things and thoughts and examples and this is, this particular one is a perfect example of, of how you just are sometimes forced to be okay with, you know, like you said, coloring outside of the box but basically saying, you know, whatever we wanted to do, whatever the default solution tells us to do, it ain't working. So we're going to have to reinvent the wheel, so to speak, or hack our way around it now.
You know, if I've learned anything from building software over the, over the past 20 years, is that generally a good developer will say, you know, everything we can do to avoid hacking around something we must do. And yet I would always say, yeah, until we do, until we have to. Because it's just, you know, I, I understand you wanted to build clean, I understand you wanted to, you want it to be as, as maintainable as possible and rely on open standards and APIs and all of that stuff. But here's the fun part. An API changes as well.
There'll be a new version of the API or there'll be a subset of the API replaced by, you know, four different endpoints instead of that one that you had. Things like that happen and change. So you need to get creative in and be more accepting of, you know, accept embracing the choice that you're going to have to hack around every now and then. I love that you bring up that particular mindset because I think I see a lot of folks just being very strict like, this is the only way we can do it. No, it's not. This is the one you've accepted. There's other ways. Sure, some of them are wild and way out there. Don't touch them.
But, you know, even though, you know, every now and then you play around with a setting and the way that you go like, yeah, I shouldn't use this, but I You know, having played with it, now I understand how to do it in a solid way. This, like, I love that. And you can see, obviously I've looked through the code and I won't pretend I understand everything that's happening there, but I can see what's happening, right? There's wonderful solutions and little libraries doing this, this and that. And I don't, again, I don't get everything of it, but it just looks smart and certainly when you interact with acts smart, it is smart.
[00:45:32] Speaker B: Oh yeah. And like, there's so many different things to touch on real quick there. But like one thing I, I like that I think is a great example of the level of power and flexibility of this. I think that with this version we have one of the best, if not the best that I know of query blocks that you can use in the sense that you can make a post query that has just about, in the UI anyway, every single option that you could think of. But through our filter, you have complete control over all of it, 100%. You can choose instant pagination, you can use post meta inside those queries. You can take an ACF repeater and you can query that and say that ACF repeater has a post object in it. And then you want to go to that post object and query all of the. And get some meta off of that post op with a nested loop thing. It does all that. It just works with all of it. The tags that you can use in those things have different transforms and other options and it's all fully extensible, including the ability to dynamically create your own custom tag ui. So like, if you wanted to make a tag, that's like the Sick Remkus message, right? And it's got to have a text field and then a checkbox for just whatever. You could register it and through the registration call and php, just say like checkbox this, text that, and it would make a UI in the modal and it's all dynamic and just works. That's great. This is all. It's very accessible stuff. Like if you're a nerd who has lots of nerd wishes and dreams, all of that's fine. But if you're like a regular person and you go, you know, I remember that they put an, it's called like special label down here at the bottom of the page and I want to just be able to put that in here. It's called post meta, I think. And you just go postman and there it is for your selected posts. And you just Type it in. A lot of these post meta solutions you see these days, they'll just list every key there ever was or something and even if it doesn't apply to the actual thing you're looking at. And so we've tried to limit that sort of thing as much as possible and like we have this really nifty mechanism for doing things like ACF handling or if you're trying to make a plugin integration that's like for an ACF like solution where you want to like use a different field thing or a different function and get post meta to look up stuff. We have a way for people to do all of these types of things.
It's a very open system. Right. But you know, going back to like what, like how do you make these decisions? I think that's a really important question. Like you're talking about the dogmatic nature of some people's attitudes and this stuff. Like nah, it has. We have to do everything super vanilla. Everything has to be this or that. I think that the key way to avoid those traps is to have a set of guiding principles that go beyond the actual thing that it is that you're making. Like we're not going to release something that's fundamentally unperformant, fundamentally inaccessible, something that has a objectively poor or not like solid UX doesn't have to be perfect. Right. But if it's. If it's not going to be above a certain threshold of quality, we shouldn't release it in the name of just releasing a feature. Right. Or things. Things of that nature. Right. I think one of the strongest principle like we were talking about the Prince accessibility principle. Right. We're not. Or performance. We're not going to make a new feature that like say the new tabs block. We're not going to build that without keyboard nav. Right. Because that's just the way that you build a thing like that. That's a principle that we have. So we figure out the way to do that performance wise.
[00:49:19] Speaker A: We say we don't be flexible in how you apply them.
[00:49:23] Speaker B: Yeah, right. Strong opinions. Loosely held is the expression that I think is. Is a really good one here. You know, you have to be flexible enough to be a realist where if you're trying to make something act in a way that's contrary to its nature and something that you don't have reliable control over. Like in testing terms you call this flaky. Right? Something that's flaky, it doesn't always act the same. It might do one thing or another. Minimizing all of that sort of risk and overhead is a huge part of these decisions. Like if you can use this core thing and it takes a fraction of the time and the UX is most of the way there, but it's not a hundred percent and whatever, but otherwise it's fine, well then sure, maybe you should. But if it would take a lot of effort to implement, it's not actually any better and it comes with these other trade offs. So it's like you have to be willing to at least consider another solution. Because our customers, like the people who buy this stuff or who download the free plugin, they don't know or care about any of this. All they know is what we've given them to use. And I think that we as makers of tools or makers of websites for other people have a sort of like, like a responsibility that we know what we know. And so even if people aren't asking, you still have to commit to doing the right thing. Yet again, another sort of principle thing that goes beyond just ship it because nobody's gonna look at how the, you know, it doesn't mean the code has to be perfect or like you have to have a CS degree, you know, to understand all these or whatever.
[00:50:52] Speaker A: None of that.
[00:50:53] Speaker B: I mean real world value.
[00:50:55] Speaker A: Right, exactly. Even within the, the diversity of one, from one developer to another developer, there's already, there can be already such a chasm between the fields of knowledge and sure there's a general thing they all that everybody agrees upon. But you know, you develop in this direction, somebody else develops in that direction.
I, I think I've said this before, but I work, I have worked and work with developers who love to untangle spaghetti coat, that's their thing. Great. But don't ask them to write something from scratch because they're lost. They don't even know where to.
It's not how my brain works. Okay, fine, then let's not have you do that. Right.
[00:51:33] Speaker B: So.
[00:51:36] Speaker A: I'm more interested in having, you know, a good look at that, that common shared. These, these are indeed the principles. This is how you do your work. You, you, you always has a have it performant, you are taking care of accessibility, you're looking into this, you know, all of these things and then get very creative in the actual implementation in as a stable way as you can figure it out while still, you know, and then all of these conditions apply.
[00:52:08] Speaker B: Yeah, absolutely.
[00:52:10] Speaker A: So last question for you.
Having built version 2.0 of Generate Blocks, having really seen what Project Gutenberg has changed in the last two and a half, three years, what you now have available to, you know, build what you just built, and this is not you. You just, you know, everybody working on this project, what is the one thing you want wish you hope you're going to see available in Core 4.25?
[00:52:51] Speaker B: I think that perhaps the most useful thing would be exposing the device previews so that people can actually properly change those. So for those who don't know, if you're in the editor and you go to that top and they got the little icon, you can say, show me the page I'm looking at in a new tab or yeah, give me the desktop, the mobile, the tablet version. And now recently they added something called a slot fill, which if you're not familiar, you should totally check these out. It's basically a spot where you can stick other things in the UI and so you can put other controls up there and make your own things, but.
[00:53:26] Speaker A: You don't have the available.
[00:53:28] Speaker B: Exactly, yeah. And you can't modify the originals though, and you still can't control the width of the actual iframe, even if you made something that was like a different. So, like, in our case, when we're doing breakpoints, we don't actually have the ability to set it directly to the breakpoint you set either. We have to kind of say, well, it's going to use the tablet one or it's going to use the mobile one. And it's, you know, that's. That's what we can do. Having control over that sort of thing, though, I think is the biggest roadblock to innovation in making that part of the editor better. Like Core may not have their own answer to that, but exposing the ability for other plugins to solve that problem like us, I think that would be a much better experience for people that allow people to make more tools and make things better for everybody. Rising time lifts all boats and all that.
[00:54:19] Speaker A: Yeah, I was going to say. There you go. Couldn't have said it better.
Thank you so much, man. I think this is a fun conversation where you know everybody who is looking into blocks and find only limitations.
At the very least, start looking at Generate blocks, the plugin, the Pro version I highly recommend.
There's not only does it offer great solution, but it also offers great solutions in how it got to those solutions. So definitely check it out. Thank you for taking the time, Ian, and joining again and giving your insights. Highly appreciate it.
[00:54:56] Speaker B: Me? Yeah, it's great.
Gosh, man, I can't even talk. It was great being here. I'm really glad to be back on. It's always a pleasure talking to you.
[00:55:06] Speaker A: All right, man. Thanks so much.
