 community. He truly is awesome. So please give it up for Zach Gordon. Hi, everyone. Can you hear me? Is this thing on? Are we on? Yeah, okay. Hi, everyone. I'm so happy to be here. I'm coming from Washington, D.C., and I've wanted to be at WordCamp London for years now, so to have the opportunity is really cool. Y'all do a smash-up job, so thank you. So today we're going to have a quote-unquote workshop. Ideally, I was hoping we'd have a good, like, three hours to get into the code and practice building everything, but we only have 40 minutes. So what we're going to do instead is I'm going to talk at a high level and then go through a bunch of different code samples and point out a bunch of things that as you begin developing on your own, you'll want to know about and be aware of. So if you have a computer, there is a code repo, and you could also get the slides at goonberg.courses slash WordCamp London and follow along there, but it won't really be something where I'll be giving you really enough time to follow along. My apologies there. So she mentioned a little bit about me. My background is in education, and I started to really focus in-depth on Gutenberg after WordCamp US when Matt was like, it'll be out in April, by the way. It's April, right? And I'd say from following it, it has developed so quickly, and it's very feature-complete-ish and has come a long way, and there's a lot of refinement still going on, but I think it's important for all of us to know the code behind it, because in the entire time I've been working on it, the only things that have really changed are like the name of this, or this referred to that, or things have got simpler to do. So it's not like the API in major stuff is really shifting. So I feel in terms of investing your time to learn it, I think you're very safe now. Now, we're not going to get into the questions of should you use Gutenberg, or does it apply to this, or can you do that as much? I'm just going to show you behind the scenes how it works. So the goal for today is to talk at a high level about the different JavaScript libraries Gutenberg introduces. As you know, it brings React and Redux and things like that into WordPress core. And then we have to talk about the whole tooling system. We are beyond the age of writing jQuery and, you know, not using compiling tools. So you'll hear me talk a little bit about this, and I'll just say that if you are of the opinion that you don't need to learn ES6 or React, and you don't want to learn how to compile stuff, you need to change your attitude about this. The entire rest of the web world is way beyond where most people in the WordPress space are, and you have no excuse not to play catch up. The cool thing is that Gutenberg already has leveled up the entire system of the WordPress JavaScript code, so it's doing a lot of it for you. We'll talk about how to pull in the JavaScript and CSS. We'll talk about architecture of a block, and then I'll just get into a big repo of demo blocks that you could learn from and download and play with, and hopefully have time for Q&A. Now, to make this a little bit more workshoppy, if you have questions as we go, please just raise your hand, and our lovely assistant here will come and let you ask. The only thing I reserve the right to do is say this is way out of scope. Can you come ask me this later, because it's going to take me an hour to explain my opinions on this, and maybe I'll say can we talk about this at the end? Otherwise, please just raise your hand as you have questions. I couldn't find my glasses before I got on the plane, so you all are an entire beautiful blur to me, so I can't really see too well, so hopefully she'll be able to see for me. A sea of just happy blur. All right. These are the main libraries I want to talk about in terms of what Gutenberg brings to the table. The first one is wp element. So React is abstracted, and what we mean by that is that if we go to the Gutenberg repo and we look under the element library, now you might not be able to understand what all this code is, so I'm just going to explain it to you. It basically pulls in all these elements from the React library, so it loads React, pulls all this stuff in, and then goes through the process of simply exporting it exactly as it got it. So if you've used React before, then you're going to get the exact same things that you would have had before, but you're going to get them referenced as wp.element instead of capital react, but it's pretty much the exact same thing. They're not changing anything under the hood, but this is really smart because if React changes in the future or we want to modify something, the WordPress API isn't going to break, and they can shift things behind the scene, so this is, I think, a really smart approach. The next thing we see is wp blocks. And wp blocks and wp components are kind of similar, so I'm going to try to explain some of the differences between them, but in wp blocks we see a lot of functions that help us build blocks. So when we create a block, we use this function register block type that's stored in blocks. All of the core blocks are also stored in blocks, so one of the cool things that you could do is come into the Gutenberg library, go into blocks library, and here are all the blocks that come loaded with WordPress, and this list will grow and grow as more things are added, and from what I hear, I've never seen this list, but I hear there's a list of more coming, so. The other nice thing about this is that these blocks are built very much in the same way that you would build your own block, so for one of the first times in WordPress we have this really beautiful well-written code base where you can almost come in and just start copying and pasting, hey, how do they get this button here? How do they get to this to this? You just go in, you look at it, you copy and paste it over, and for the most part it really works, which is really cool and kind of a new age in WordPress development. Now, we also get inside of blocks some other helper things, so if we want to add a toolbar or we want to add the inspector bar off to the side, these things that are really tied to block specifically, all of these little snippets of code are built for us in existing blocks. Then we migrate into components, which is a kind of higher level folder, so things that maybe the editor uses or something that's super generic, like a tool tip, a button, a panel, things like that that are more generic are going to be in components, and my guess is that as Gutenberg slowly begins to evolve into more and more of WordPress, you will see this library grow. The cool thing about this is that if you go to start building new eyes, we can rely on the core WordPress UI elements instead of needing to write our own CSS, write our own HTML, and we can really just drag and drop and say, hey, I want a button, give me a button, and it gives it to you, and that's so nice. I don't know about y'all, but sometimes it gets a little under my skin when you install these different themes and plugins, and they're like, yeah, making the whole thing orange with white text would be a great idea, and we'll completely shift all of that into the next slide. So, I think hopefully what we'll see is a more uniform UI, and I'd like to personally encourage you and ask you to follow these conventions and use as many of the built-in components as possible. If you're not familiar with the term component, it's just a little snippet of code that can be reused and usually comes with its own styling, maybe a little bit of functionality built in out of the box. Go-go internationalization. So, I will let him extend on that, but hopefully if you've ever built anything in WordPress, you've used like underscore, underscore, underscore e, or escape HTML, underscore, right? Yeah, I can't really see hands, but yes, I'm going to assume everybody said yes. So, this is super that we now have this on the client side in JavaScript, so we can have all of our JavaScript strings of text be translated super easily. So, you'll see anywhere in a Gutenberg block or in Gutenberg code, you want to have text wrapped inside this underscore underscore function, which we'll look at. Finally, we have WP data and some offshoots of it. And if you've dealt with complex JavaScript applications before, at some point, you need to begin keeping track of the state of the application or what's going on in memory. You can't save every single interaction to a database and reload the page or depend on AJAX calls to save everything to some backend. So, much more is done live in memory. The cool thing about this is that the core team is starting to load up a bunch of data into this automatically. So, if you want the post ID, you want this information, you want that information, you don't have to write your own queries. You can just say, hey, data, give me this. Hey, data, give me that. And you could also begin to create your own data stores. So, if you're someone like the fabulous Yoast team that does crazy complex plugins, then you have this at your disposal to basically keep track of all your application's memory. So, these are the basic libraries. We'll get into most of these top four ones. The data is a little bit more complex, so we probably won't get that far today. And the interesting thing about these is that these are global variables, which should make every JavaScript developer in the room go, that's probably not a good idea. But I've kind of grown to like it, and I think what we're going to see here is an evolution. So, right now, there's a lot of code inside of Gutenberg that just lives in Gutenberg. And little by little, they're going through and pulling this out and throwing it up into npmjs.org. So, now we're starting to get a bunch of WordPress packages. So, the modern development workflow, whether you like it or not, is to import a ton of different packages into your application and rely on those for a lot of the heavy lifting. So, right now, when you want to build a Gutenberg block, you have to access global state. And I'll talk about what that means and show you some examples. Behind the scenes, they're starting to put more and more things in packages, pull them in for you, and then make them available in global state. We will get to the point, and it is starting to evolve to, where if you wanted to pull these in directly to your application, for maybe testing reasons or something else, or maybe you're starting to develop with Gutenberg outside of WordPress, do you all know there's a standalone Gutenberg editor? So, you could just start using Gutenberg on its own, completely outside of WordPress. So, eventually, we'll get to see more and more packages outsourced in this way. And whether we access them through a global variable or packages directly will depend on just how things go. I'm not sure. But I can say, in just the few months that I've been working on this, some of these libraries have been super helpful, like browser list config. So, our Babel files will show you used to be this big, and now it's just one line saying, well, I'm just going to use what WordPress did, and we go from there. So, we have a wp object, and if you haven't played with Gutenberg before, or if you've played with JavaScript and WordPress, you probably have never needed to access the wp object. It exists in the admin, and on the front end, you get a lot more when it's loaded into admin. But if we do wp.i189, we'll get that entire library. If we do wp.element, we'll get the entire React library. Just to show you real quick, what I mean by that is that if I come in to something that's not broken, and I open up my inspector, and I type wp, I get this huge object, which has all of this stuff built into it, including things like element. And when I open up element, this is the entire React library right there in global scope. Now, we probably don't want to be writing out all of this in super long format, so we use something called destructuring. I can't just simply refer to it as deconstructing in my entire JavaScript course. It's torched in here. Okay, there's someone here who wrote a great review of the course and pointed out that I incorrectly referred to it the entire time. But basically, what this allows you to do, if you have something called wp.element.component, you could write it in this way and then just refer to it as component by itself. So at the top of every, or most of the Gutenberg files, you'll see something like this where we just pull out everything that we need so we could refer to it by shorthand. It's not necessary. You could write wp.blocks.richText every time if you wanted to, but I don't think you want to. And I've just been following the conventions of the core devs, so that's what I would suggest for you. So let's move on to talking about tooling and enqueuing. The main tools I'm going to talk about are Babel, Webpack, and NPM. And then we have two new hooks inside of WordPress. You've all enqueued a CSS or JavaScript file, right? Okay. Otherwise, I'm not sure why you're in a Gutenberg development workshop. But hopefully this isn't new to you. And you've used wp.enqueuescripts to pull in scripts and styles before. Now we have two new ones. So enqueue.blockEditorAssets will take all your JavaScript and CSS and load it on every page where Gutenberg is active. I imagine this might adapt as Gutenberg starts to reach into more places, but right now it's just in the editor. Excuse me. So if you wanted to build a block, you hook in your JavaScript using this first hook here. The other thing about Gutenberg is that we want our styles in our blocks to match what they'll look like on the front end, right? So most of the CSS we're going to use enqueue.blockAssets so that the same styles are applied on the front end and they're also applied in the editor so that you can see them both. So what you're usually going to find is that your JavaScript will be enqueued with enqueue.blockEditorAssets and your CSS will be enqueued with enqueue.blockAssets. There's some variety to this, but in general it works that way. I'll also throw out if you're theming and you want to design blocks to look a certain way for your theme and you use the normal enqueuing process for a theme, they'll look that way on the front end, but they won't look that way on the admin. So there's some discussion around how is the or what's the best way to approach this and I think it's still being talk to Tammy later, she'd be happy to give you some insight there. It's being evolved, but just be aware of that when you start styling for blocks and of course you want your theme to make all the blocks look the sexiest, right? So you might have to do some enqueuing on the back end as well for that. Or you might not. Let's talk about tools a bit. So in this plug-in repo, again, if you go to Hootenberg here, here are the slides, and then this is the plug-in repo. So you can get all the stuff I'm talking about here. Put all your blocks in a plug-in and that's what this is, is just a plug-in. Okay. So the first thing we'll start with is Babel and what Babel will do is take advanced JavaScript that cannot yet be processed in the browser and rewrite it in a way that can be processed in the browser. It'll also allow us to write HTML-like text in our JavaScript and translate that back into CreateElement and CreateTextNode and all of these things behind the scenes. The first version of this course, interestingly, was if you look at the Babel file for this, notice that we used to have to set up all of this. Actually, I've ripped out a bunch of stuff here. There should be more in here that lists exactly what kind of browsers you wanted to support, how far back you want to support, and you have to tell it that, hey, we're going to be using JSX and use WordPress's JSX to help process this and some other stuff going on. But because WordPress is pulling these out as separate packages, I can now in my configuration say, hey, just use the WordPress defaults. And this is really cool because what I imagine is over the next year or two we will be able to stop having to determine in independent agencies what our standard should be, and we could just say, hey, we're following the WordPress standards of what browsers we will support. I don't know if that's going to work for everyone, but I imagine for a lot of people it will take the load off to just blame WordPress or thank WordPress, depending on your opinion there. So more and more configuration files are going to get simpler like this. They're working on ESLint. There's an editor config that you could borrow from WordPress as well. Our Webpack, I would take the rest of the time to explain this, but basically I like this Webpack file. If you're interested in Webpack, come talk to me later and I will wrap about this with you. Why are my... This is all white. Hold on a second. Live coding examples. Let's try that, shall we? No. That's strange. Okay. I'm going to go dark on you guys because at least then we'll see it. So, I'm going to go back to the things like parentheses and curly braces are kind of important for our code. So what this is basically going to do is run through all of our JavaScript files, all of our SAS files, compile them down, and then it's going to take anything that's named editor and anything that's named style in terms of this could be SAS or CSS, and it's going to save them into two different files. So everything that's labeled as editor will be saved to a block.editor.css, and everything that's saved as a style will be saved to style.css, and then those will be loaded by our plugin on the front end and in the back end, depending on how they're named. The other thing that we'll see is a lot of these plugins that you build with a bunch of blocks will have an index file that will list all of the blocks. So this is kind of what we tell Webpack is our entry file, and then it will go from there and start finding everything. I'd really like to encourage folks to follow the naming conventions that WordPress Core does. I've seen a lot of, like, examples and kind of generator stuff that name their main block files as block.js, and I think this is a really bad idea because if in the React JavaScripty Webpack world, if you name something with index.js, I could just refer to the folder and it will find it automatically. If we're naming our main index.js file, block.js, we have to manually refer to it as block.js. The other thing is that if we look at any of the core Gutenberg blocks, find a more complicated one. Notice that they have an index.js file and it's going to be the registration of the block, and then they have a block.js file where they break out any real complex stuff for building out the edit functionality. So if you're naming your main file block.js and then you pull out something else, like I just, I don't love that pattern. So please name your stuff, follow the general React JavaScript naming conventions of index for your main files. We have a Webpack and then we have NPM. So as I mentioned, the conventions today are to reference a bunch of external things, pull those in and then run your code based off of it. Not all of these are necessarily needed for every project, but this is what a fairly common block project will look like and I gave it to you in the spoiler plate. Some of these are dealing with the transpiling of your JavaScript. Some of them are dealing with processing your JavaScript and then we'll see more and more like this that are at WordPress something that are pulling in WordPress conventions. Tooling in three minutes. So now we can start talking about the actual architecture of a block and then we'll jump into some examples. How many of you here have coded a block before? All right. So to build blocks we use a function called register block type and this is a JavaScript function that has a bunch of different, well it has two parameters and a bunch of settings. So right now most of the blocks are being registered in JavaScript. What that means is that WordPress builds your whole site, it launches the editor into the browser and then once it's in the browser it figures out what blocks are available and it makes those blocks available. It's pretty slightly problematic and there's been a lot of discussion about should blocks be registered on the server side. If we are building blocks that WordPress is not aware of at the server level then there's some things that we cannot do with them very easily like how do we figure out based on user permissions what blocks we should display or how do we figure out what are some other things? There's some security stuff. Post ID, so there are some things like how do we figure out the context of stuff that's going on. Actually post ID is now available in the data store so you can get that on the JavaScript side only because WordPress is going on the server side pulling out all the data feeding it up into the JavaScript data and making that available. But in general there are some things that you do need to register a block on the server for. So it's kind of weird. We have register block type camel case and we have register block type underscored for PHP. They both exist. This is a little confusing and there's probably going to be an evolution of naming conventions where you could use register block type in your JavaScript but if you're registering a block on the server you'd call register block type in your PHP and then in JavaScript you'll still need to add some things and maybe it'll be called extend block or do something more. So that's what we heard exactly what this will be but there are discussions on this. Now you don't, in a lot of cases you don't need to worry about the server side and the client side will work fine. The other reason that they're not going to pull everything out into the server is that Gutenberg ideally can still work as an independent editor completely outside of WordPress so if you're building your own app and you want to use this editor then you could use it and you could have inside of your app. As I mentioned register block type takes two parameters, a name and settings and these settings are as follows. I think I have them all here. We have a title, a description. Right now there are four or five set categories but I believe that categories will be extended so that if you have a suite of blocks you can kind of have them visually available in one area. I really love that you can add your own SVG icons so if you have any icon you want and just convert it into a react style SVG, throw it in there. Keywords, you have a bunch of different ways to search for block and I'll give you a little hack because you can only have three keyword strings but it will search for independent words in each one of those strings so I'm not encouraging this but I am letting you know it's possible you can completely like black SEO it and throw in a billion keywords I think and it'll find it easy. There are some things that you might want to turn on and off for block functionality for supports. There's not too much to this now but if you use Gutenberg for example it spits out an automatic class name on the front end to all your blocks you could turn this off. In editor there's always a little CSS class names thing where you could add CSS to your block. You might want to turn this off for certain users because they might start looking at you and they might want to turn this off. There's the ability to say hey don't let somebody edit the raw HTML of my block they're going to mess it up so you could turn that off things like that. Attributes are probably for me the most confusing part of Gutenberg when I got started but basically when stuff is stored oh man yeah we don't have time to explain attributes in enough depth. The basic aspect is anytime you have to keep track of that and it took me a while to figure out exactly what that model was so just rest assured that if you're sitting there like it's going on you're not alone. That is my experience too. And then the last two are kind of the heart so these last two are the biggest part of your block where you have to code out all edit functionality for your block. Like I said you can get components you can say hey give me a button to upload thing but you have to say what happens when they upload that image right do I display that image do I put it here what do you want to do with it when they click this button what's going to happen so you have to code all of that yourself which is following the React format it's not too bad but the edit setting is going to be where you code your entire block in the editor. The same setting on the other hand just determines what format it's going to be. Most blocks will write your save function in javascript there are a few blocks where if you're keeping track of metadata or something that can be changed in other places in wordpress while that data is stored in the database it actually saves as blank data in the database and renders with PHP so sometimes the save function is completely empty it really depends on what you're trying to do but for the most part this is all going to happen. This is a very limited view of it but this is what an average block registration will look like so take a moment to look this over you'll see a few things here like underscore underscore that means that my block can be translated and you'll see that the edit right here is returning a function actually so it can be called and executed and this block will do nothing in fact probably this would not be a worthy block to do but it gives you an idea of what you're going to see as we move into the demos. So that's all of Gutenberg development I have a course on this by the way where I take about three hours to go over what I just said so if you're interested in any of that in more depth you can check that out and I'll just pause real quick does anybody have questions about stuff before we jump into the code at kind of a high level here? Nailed it. All right so the most basic and probably least helpful block you will be able to build is what's called a static block and this is one that is completely uneditable and I'll just kind of show you real quick what this would look like here we have a block you can't edit it you can't do anything you can add some css but this is all just hard coded so what are some use cases for this maybe you have a site where you do want to hard code blocks maybe it's a warning maybe it's something that just doesn't change for some reason this would be what it looks like more than likely you're not going to build these however your static block is going to be your basic starting point for whatever you do so there are some things in here I just want to take a moment to go over that you probably won't build but sort of form a foundation for everything else you would want to do I like to break my blocks up pulling in files in two different ways so I usually try to put block dependencies which are my own code first so in this case I'm importing an svg icon so I have a file here called icon and I like the noun project so I just copy my stuff from there and use that and what that is is if I search static see the little lego lego and so this is what obviously this is a lego svg icon right you could all tell so I have that file being pulled in and I'll show you where I use it in a moment and then I pull in my front end styles and then my editor styles and most of the time like I said you won't really be having styles that just go on the editor side then we come down into word press dependencies so the next thing I do and notice that this is using import right because these are separate files that javascript is importing then web pack is going to go through and pull them all together with all the word press dependencies we're using that destructuring so it's not actually importing anything so we could leave all of this out and everywhere in my code where I have underscore underscore I could just type wpi 189 like that and remove this line of code okay so this is purely for convenience factor only but I would highly encourage you to do this up here so anything that you need from word press you're going to pull in up here and what we'll see is as we get into more complex things this list grows right so that's going to get bigger then we come down into our actual register block type there's two parts to a name you have to name space everything and then you have to give your block a unique name what's cool about this is that later on in word press it's going to do something like is it blocks player blocks singular it's going to apply a CSS class like this to your block so at some point you'll be like where is that name coming from and it's coming from basically the hardcore name your block you'll also need to use this as you get into some more complex blocks sometimes you need to register a block on the server side and you follow the same naming convention I don't actually know I haven't actually tried I should can you put multiple namespaces in a single block or in a single plugin like can I have some blocks with one namespace and some blocks with another okay we'll find out one day I name them all the same I imagine you can but in general this is going to be like your plugin name or something like that generic we have the title and description I'll just show you real quick where these show up in a block if we I really love that they added hover over blocks thank you design team that's so cool if we click into a block notice this description over here and we've got the title and when you're searching for a block you're going to see all the names of the blocks here so that searchable name is what the title is and the keywords here I'm going to jump down to notice that the word banner is nowhere in my block title but if I search for banner you all know this you watch the word camp us talk that that is going to be there so the next thing we have down here is category like I said there are a few default categories we've got common blocks formatting layout widgets and then we have our embedded blocks so you could define where you want your block to go sometimes it's a little confusing where your block should go and then my understanding is that eventually this will evolve I think so that you could have my blocks category and set up your own one but right now you cannot icon a little just sex for you this is basically just referring to the icon that we pulled in before your keywords and then we get down into the actual edit functionality so I'm going to skip at this point to a more complicated block that allows you to edit stuff like this one I've got five minutes left so hopefully I can get through this one example form fields okay so here's a block with a whole bunch of editable stuff you'll notice that it's got form fields here and it's got form fields here and they're mapped to each other you would never do this right but just for demo purposes to see how this would work so in a more complex block like this I'm going to break out functionality into different places so if I come down to register wait notice that I pull in this thing called edit and when I go to do to load like an inspector I'm going to pull in these other files and so at this point I've taken all the edit functionality and broken it out into its own file so eventually you're going to get to the point where your stuff becomes so complicated that you need to start pulling files out separately and this is where you would do that I'm also doing a lot of things every single one of these form fields is a built in native component in wordpress so I did no custom coding here to do any of these things and I think that that is so cool that we get all of this out of the box so I'll just show you real quick remember I said that there's the components library you can go into components and I've got a checkbox control a radio a range a text all these different ones set up and then I just want to show you one last thing here in how they work so whenever we have a form element or something like that there's some baked in like labels and things like that and then there's a better one the color palette we pass in a default color palette so if they've already saved this block we load that value automatically and then this is the very reactive way of determining how a block should be handled on change and this is probably going to handle like 90 percent of your save changes well maybe less depending on the complexity but you basically say hey every time this color palette gets changed take the new value go back to my list of attributes or changeable elements and give me the new one so this is this is all the wiring you would have to do to make this entire thing work all you have to say is appear give me the color palette and then down here set the default value and then determine what happens on change and you'll see some of these are more complex like you have to set some default options but they all follow this basic convention of value and change so at this point we have two minutes left and I wish that I could take you know like I said many more hours the course I have is about five or six hours long and you could go through that for more on this I'm also happy to answer questions afterwards I'll put this up here for anybody who's interested and then I don't know probably not time for questions or maybe one or two or let's do this come find me afterwards if you have questions I'd love to chat more about goonberg and thank you all so much for the opportunity to come here and talk with you all