 All right, yeah, so if you're here for Gutenberg, you're in the right spot. If you're not, I won't be offended if you need to go to another room. But yeah, so this is a developer talk. We're going to try to hit things from kind of a high level at first and kind of give a little bit more background. And we're going to try to make block creation dead simple. I had five hours practicing trying to explain this the other day. So hopefully I'll get it right today. So yeah, so my name is Michael Wood. And I worked for a company called Narwhal Digital. And the interesting thing and the reason why I'm speaking on Gutenberg is because I've spent probably the last four years giving or not giving, building a custom page builder. And I've iterated on it about five times. Then I rewrote it completely from scratch. And ultimately what I ended up with is very similar to Gutenberg, but different. So it's kind of a unique situation that I'm in where I've got a lot of experience in building custom components or blocks like you would with Gutenberg, but for the things that I've been doing. And they're structured very similarly. So yeah, so that's kind of what I've been up to. And I never thought I was going to actually build a custom page builder. That's not something you'd go in. You're like, oh yeah, hey, I'm just going to make my own thing because there's a million other things that are out there. So why do I need to build my own? Well, so I do enterprise WordPress development. And the issue there is when you're building for enterprise, particularly when you're building for a large enterprise client who's very strict about their brand, right? You don't want to just put a page builder up and allow anybody to change text colors and font sizes and all that kind of stuff. And a lot of the page builders are out there. They give too much control to the user. So we want to make sure we kind of lock things down and keep the design in sync with what the expectation was there. So ultimately, the other issue was for security, right? So if we use somebody else's tool, then we also have to run it through security. And if it doesn't pass security, then I have to fix it. And if I have to fix it, now I'm maintaining it. And then if they update it, then it has to go through security. And then if it goes through security that passes again, then I have to fix it again. So I don't really want to maintain somebody else's code. If it doesn't work, it's going to be my fault, not rather it be that way. So that's why I kind of went down this path of building my own page builder. So now I'm in a situation where we've got clients and they're interested in Gutenberg. They've heard a lot about it. They think it's interesting. So do we build on it? That's the next question. And apparently my, there we go. Yeah, so do we build on it? In my opinion, I think the answer is yes. I think it's come a long way. I think it's in a good place. There's still plenty to do, but depending on your client's use case, it's absolutely something you can build on. So right now I'm working on a project that in a few months will launch, probably about beginning in July, and this client site will go live with Gutenberg on it. And it'll have about 40 custom Gutenberg blocks and a bunch of custom page templates. So there's some things though that I know Gutenberg is missing that we need to launch the site. But it's something I've done in my own stuff, so my goal is to hopefully contribute back. So anyway, so that's kind of my background in page building and Gutenberg and kind of how all this works. So my goal today is try to make Gutenberg development as simple as possible to help you understand it, but also to try to kind of give you some of the overall principles or kind of lessons that I've learned along the way. So, oh yeah, and that's me. I work at a company called Narwhal Digital and I just kind of told you what I do. But if you want to contact me, my website's WPscholar.com, Twitter, WPscholar, and so on. But yeah, so let's, oh shoot, okay. Apparently I never actually changed that slide to be not generic. But anyway, so what you see in the little computer screen there is something called design or atomic design, right? So this is something that Brad Frost blogged about. He's got a great article if you wanna go look it up. But the whole concept here is that you've got atoms, which are kind of like the basic building blocks of anything in this world, right? Well, of course then you have electrons and whatever. But you know, they're very simple, basic building blocks. And atoms make molecules and molecules make organisms. And then yeah, there's templates and pages, but that's because we're talking about page building, right? So ultimately, we're gonna kind of go through from this angle and take a look at how these principles apply and why this makes sense in the context of Gutenberg, right? So atoms are the basic building blocks, like we just said. So we're talking about essentially HTML elements. Those are the most simple things that we have to output or display to a user. So we've got input fields, we've got labels, we've got buttons, we've got all these basic pieces that we have and we can kind of tie them all together. So in this case, we're gonna go from there, take our atoms and create molecules. So these molecules are basically groups of atoms. And these aren't things we're gonna force together, these are often naturally occurring, right? So in this case, this is a little form element, right? Usually you've got a form and inside of the form you'll have things, but at a more basic level, we're talking about an input with a label and some sort of way to submit that thing, right? So a lot of times you see it with images inside of a link tag, right? So that's two things that kind of come together naturally, you see it a lot. It's a very common pattern. So these are kind of those molecules or more advanced things, but still pretty basic that we can use and reuse across the web. So then we have organisms. And these are essentially where groups of molecules have come together to create something more complex. And so in this case, we've got a header and it's using our molecule, our little search bar or search functionality. And we've got a couple other molecules or things that have come together. So we've got a list, right? So you see these all the time where you've got a menu and it's just a list. It's a UL, LI. So you've got another molecule coming together. So all these come together and you start to see these templates or whatnot coming together. So these are templates are essentially when you take all of these molecules or organisms and put them together, right? So you kind of stitch them together and you create these layouts. So everything in here, you have atoms at the very core level. You have these naturally occurring molecules and then you have these special organisms that you create and they often get reused or maybe they're global, right? Like a header or a footer. And then you have these templates. And then after that, we have pages which are essentially, so if you think of the template is like the generic layout. So it's a layout that you might use across a whole bunch of pages but pages are specific instances of templates. So in that case, we'll actually have content. It's very specific content on this page. But if we look at it, essentially everything, if you think about Gutenberg and Gutenberg blocks, everything on this page can be a block, right? So we can have blocks and we can have blocks that are nested. At the moment, Gutenberg doesn't support nested blocks so that's functionality that's coming. But what we can see is we've got our, for example, this big image up here at the top. That's maybe like a hero image block. Maybe it has a title that you can assign to it, right? And then we have maybe two columns and then each column can have any kind of block go inside of it. So we got text and we have an image with text and of course the image is its own block and the text is its own block but the way that they work together gives us a slightly different look or feel to it. So that's basically the idea and the concept behind Gutenberg is that everything's a block and even though it isn't now in the future, the header itself could be a block. Think about having a block that can have a bunch of blocks inside of it but it's a global block so you can have that one thing, you can change it and it changes across the entire site. So this is the kind of thing that, or the direction that Gutenberg is heading. So I wanna kind of approach this from the standpoint of the classic approach to working with blocks, right? So if we have this big text editor where we can just plop a bunch of content, you could put images in, you might could put little square, anything that's square, right? You got images and videos and there's only so many things you could put in there before you have to start having custom functionality, right? So how do we do that? Well, it's been short codes up until now. So if you wanted a button, well, there's no way to actually put a button in unless you know HTML, which most people don't. So you end up with short codes that do things like display buttons and sometimes people make it easier than actually having to remember and know the short code but a lot of times these short codes are not really easy to use, right? So this is the view that you get in the editor and on the front end it'll show you a button but on the back end all you get is this nasty short code and how does the user know that the short code's there because they installed the plugin or the developer told them it's there and hopefully they remember that there's a button short code otherwise they may decide to install another plugin thinking that it's not there. So it's kind of like a hidden feature, nobody's aware of it unless they were taught, right? But then how do you work with short codes? Well, there's attributes and you have to pass the stuff into it and some of them might have content but how do you know what all the attributes are? Well, hopefully you know how the short code works and how the developer made it because if you don't know that you're not gonna be able to use the short code. So we talk about Gutenberg and I hear a lot of people saying oh well Gutenberg is complicated, it's difficult. Like is it really? Like we actually have clients that know how to do all this stuff and yet we're making it a whole lot easier on them and supposedly it's a problem. So this is the Gutenberg approach, right? So there's actually a button component. So you don't actually need any additional functionality, you can drop that button component in there, you can click on it and it goes straight into, edit the text on the button and right below it you can click and change the permalink or the link to it. But then you also have this kind of bar over off to the side where if you wanted to do something more advanced you could do it. Like change the button color, the text color, maybe you've got text somewhere on there, you could turn the wrap text on so you could have the button kind of float within the text much like you do with images. So all this is pretty cool functionality and that's kind of the way that Gutenberg is heading. So I wanna kind of take a look at it from the standpoint of if we've been using short codes previously, what does it look like moving to Gutenberg and creating blocks? So I know we have a lot of developers in here. So what are the steps? If you wanna create your own short code, what do we do? Somebody throw out a few. Okay, yeah, so you have to register, you have to call the add short code function and you have to register it, what else do we do? Yeah, so we have a call back so that we know what's being output on the front end. So we're outputting some sort of markup on the front end and then there's something else over here. Yeah, we gotta set up all the attributes, right? So we have to dictate what the user can pass in so that they can control how that thing works. So essentially, Gutenberg blocks, they work exactly the same way and if you think of it as the evolution of the short code, it'll make a whole lot more sense as you're moving forward and trying to develop. So, and the other cool thing is that, again, with short codes you have no idea what's out there. Well, in Gutenberg we have block discovery, you just click the plus button and anything that's registered in the system is actually visible and easy for the user to find and so it's kind of a cool, cool feature. So we're gonna go straight into creating a block, right? So same thing we do with the short code, we have to decide what we're actually gonna output on the page. So ultimately, the interesting thing with Gutenberg block is you can actually have the editor itself generate HTML and save it off to the content to go into the database when they click publish or update. But you can also create a block and then have PHP render just like a short code does, something more dynamic at the time that the page is rendered. So we're not really gonna cover that part but it is something that happens and you can go to the documentation and kind of find out more about it or I'm happy to answer questions about it but so what we're trying to do is just talk through, if we're looking at it from a more short code perspective, what does that look like? So first thing you do is you figure out what your markup is. So this is an example I gave previously the other day is essentially a block that displays information about a book, right? So you got a title, a description, an author. So we're basically just creating some markup and outputting these different things. And of course, I like to use BEM and it makes a whole lot of sense in Gutenberg and you'll find out why when you start trying to style things in the editor because it adds some extra divs and if you're reliant on your HTML structure, you're way better off dependent just styling on the classes themselves. But yeah, so we're creating our class names and as you can see, we kind of have this class name WP block, WP scholar Guten book. And the way that Gutenberg works, it automatically prefixes anything that is a WordPress or Gutenberg block with WP dash block dash. And then the name of your block, which is gonna have some sort of a namespace and then you're gonna have a name for your block, right? So this class is auto-generated essentially. So that's why we are using it here. So WP block, WP scholars the namespace, Guten book is our block name, right? But then with the BEM approach, so that's our block and these are the elements inside of our block, essentially the title, description and author. So we just use double underscore and then the class name. So if you're not familiar with BEM, it's a thing, CSS, it's been around for a long time. It's not a Gutenberg thing. So if you're not familiar with it, go check it out. But yeah, this is just basic HTML and we wanna put it on the page. So you gotta figure out what that markup looks like and you probably wanna go ahead and style it and you wanna test it across different browsers and all that before you actually go and build the hard part so that you don't have to go and change everything later. Yes. Actually it is supposed to be double underscore author. Yes, good catch. So that'll be incorrect on all the slides going forward. So yeah, so step two, we're basically gonna replace all of our placeholder content. So in that case where we add an actual book name and author and description, we're just gonna put JavaScript variables and wrap them in curly braces. So we're starting to convert this into the language that Gutenberg is gonna understand from a JavaScript perspective in order to render our content. So at this point, we just arbitrarily decided on a name, something that makes sense, title, author and description and we put it in curly braces. So the next thing is we want to reactify our markup. So for those who don't know, Gutenberg is based on React, which is a view library published by Facebook. So if you're wanting to find out more about Gutenberg development, it would be very helpful to know and learn more about React because when you get certain errors in the console, Gutenberg's not gonna be like, oh yeah, you should do this. You need to know a little bit about React to kind of figure out what those mean and find them out. And just being able to know, hey, I should Google React and then whatever that error message is in the browser is gonna get you a lot further. So yeah, so ultimately when I say reactify, the thing that's different here, anybody see the difference between this and this? So this and this. Yeah, so the class name. So before we had actual HTML where it was class equals, blah, blah, blah. And then here we have class name. So the way that React works, they have something called JSX. And so it's essentially a JavaScript HTML, it's putting HTML in your JavaScript. So you can't actually use class in JavaScript because that's a thing in JavaScript in ES6. So it's a reserve keyword. So you actually end up using class name, which is kind of all along, they've been using that in JavaScript as the class name. So if you really wanted to change the class name in JavaScript, you would have to use class, with capital N, name. So in this case, we're just changing that so that it works more, works better, works correctly with JSX. So essentially any attributes on HTML looking elements in JSX, they're all gonna be camel case and they're gonna start with lower case letter. And you can also add handlers like onClick or something like that to your elements as well. But we won't cover that now. So all we've done at this point, we've put in our JavaScript variables, wrapped them in braces, we've chained class to class name. And so this is becoming actual JSX at this point. So now what we're gonna do is we're just gonna wrap this in a function. So WordPress has kind of two things. We have a save and an edit. And so really the save is nothing more than the HTML generation that we're gonna output on the front end of the site. So if you think about a short code, all you're doing is you're generating markup to be rendered on the front end. Well, this save function is doing the exact same thing. We're taking information or attributes that the user has passed in just like they would set on a short code. And we're taking those and we're rendering the markup, except instead of rendering it on the front end, what's happening is when the user makes changes in the Gutenberg editor, all of these things are being tracked and the markup is being generated. This markup is being generated behind the scenes. And that's actually what gets saved into the post content. So all you're doing is generating the markup that's getting saved into the post content. So we're using ES6 and we're using JSX. And so in ES6 we have something called deconstruction. And so we actually have, if we did this in regular JavaScript, this function would have a props argument that's being passed in. All we're doing is we're breaking down the props object and we're fetching the attributes value from that. And then inside of that attributes is an object that is going to contain all of our attributes for our block. And so as you can see, we're also deconstructing all of the attributes that we know are gonna be there from the attributes as well. So if you're not familiar with ES6, I'd recommend you look into it. It's really handy and makes your code a lot cleaner and easier to follow JavaScript. If you're familiar with the standard JavaScript, it works well, but it's also a lot more verbose and this kind of cleans things up. And there's only a few little things I think that you'd need to kind of wrap your brain around to really start to follow it and start to use it well. So then in, I don't know if you've used Node before, but essentially the process that we're using here, we'll talk a little bit about the fact that we're doing this build process and there's things happening. Essentially what we're doing is we're using Node and we're compiling it to browser safe JavaScript. And then we're gonna use that. But this makes it super easy for us to actually write our code and keep it nice and clean and modular. So this is actually the entire file for our save method. So you know how in PHP we create classes and we put, it's the best practice to have one file for one PHP class. So it's no different than in JavaScript, we're basically creating a React component and it makes sense to have one file with one React component inside of it. So in this case, our React component is what's called a functional component which is a very basic component and we already have all the properties coming in that we need so we don't really need to do anything fancy. So all we have to do is return the markup and take the values that are passed in and make sure they get set. So that's exactly what we've done and we're exporting down here at the bottom something called save with capital S. And just so you know in React, if you ever tried to use a lowercase letter for a React component name, it will not work. So you always have to have an uppercase letter at the beginning of your function or the thing that you export so that React will actually identify it as a component. So that's how you create your basic HTML rendering on the for content into the post content area. The other side of this is to actually create an edit component in React. Now the only difference really, so we're doing the same kind of approach. We've got a React component or functional component that we're creating called edit and we're exporting that so we can use that wherever we need it. And it may be that some of these components you end up using in more than one place which is why you'd want it in its own file. But as you can see, we're obviously generating some markup here but this is not your average HTML markup, right? So we see we have a div and we have a class name, camel case, class name, and we're passing in class name. So when you're creating an editing experience in Gutenberg the properties that they give you in Gutenberg include the class name because remember Gutenberg is auto generating, I was talking about how it auto generates our class name. So really we're just taking the auto generated class name and we're using that in our block here. Because one of the things that happens too is that the user can actually add additional class names to any block. So if we hard code that, that functionality doesn't work. So we actually wanna use this dynamic class name variable to put that into our component so that we get our auto generated class name that Gutenberg has but we also get any custom class names that the user adds to our block in case they need to do special styling or whatnot. So then the other thing here is that instead of having child divs you can see our class names are still there, they're still the same, there's nothing different there. So that helps you identify which thing is which. But we're using something called rich text. Now it's actually, there should be an import at the top of this that says import rich text from wherever. But ultimately it's also WordPress provides global variables. So there's a global which has been there for quite a while now called WP. And with Gutenberg there's a few extra libraries that get added, one of those is called blocks. So if you get the wp.blocks library global variable inside of that is something called rich text which is a component. So you could actually replace rich text here with wp.blocks.rich text and then you could use that. But ultimately, so this is a, we're creating a rich text component instead of a div. And so because this is a react component instead of an HTML component which is just outputting HTML this actually has functionality associated with it. So what's gonna happen is if I use this rich text component and someone clicks on the text, that text is now editable, right? So this is kind of the way that you can click to edit text in Gutenberg is just use the rich text component. So we can assign a class name and another thing that's interesting here about react is that when you have, so in JSX just a little background here you always have a root element but those elements can have multiple children but react in order to know which child is which needs a key. Essentially it's like a unique ID so they can know what component is which. Especially if you get into like reordering things react's gonna have to switch things around and if you get the key or don't set a key or the key actually matches with another element that's on the page react away confused and it can't figure out what's going on. So it's important that you have a unique key for each of the children that you add in there. So in this case we're just setting it to be title, description and author, just strings. Again in JSX anytime you have a string that you're passing you put in double quotes but anytime you have any other kind of data it's going in the curly brackets and then you pass your value. So there's no double quotes on that. I made the mistake when I was first learning of putting double quotes on everything and then nothing worked. So yeah so you have your key and then we also have placeholders. So placeholders in Gutenberg are very cool because when the user first adds the block instead of seeing nothing and yet being able to click and add text they actually get a placeholder which means they can click on that placeholder and they have a better idea of A what it should look like before they actually put content in but they also have the ability to kind of see and get a better idea of what that content should be and should look like. So in other words if you're expecting a URL maybe you're expecting it with the HTTPS or without it maybe it's just a domain. So the user may not know that but a placeholder can quickly communicate that and give them a nice place to be able to click and see what's going on. So then we also have the value and the value is nothing more than the title in its current state. Of course the user is able to edit it now so the value is gonna change so we have to make sure it's dynamic. We have to use this title for our title field and so on. But then in order for things to change properly and for React to update and for Gutenberg to know what all the correct values are at any given time we have to have an on change function. And so again all of these kind of multi word especially events that can happen in JavaScript. So in JavaScript it's just called change. It's all lowercase. But in React you pretty much just add on and then the event name, chances are it's already in there and you can just throw a function at it and it'll work. But the on change is very commonly used with pretty much any editable thing in React and you're gonna pass it a function and that function is essentially going to give you something and you can extract the value from it and then you can trigger essentially an action that will cause React, cause Gutenberg to update that value for you. So there's no need for you to do anything beyond that in terms of saving, right? It handles all that for you. So in this case our on change for our title block we're using ES6 arrow functions. So what's left of this equal signs greater than symbol is the arguments that are being passed into a function. And what's to the right of that is essentially what that function is doing. And when you are not doing a whole lot you can make it all in one line which makes it very succinct and it makes these things a lot easier to read. So we're basically being passed the title from the rich text editable component provided by Gutenberg and we are passing it to a function called set attributes also provided by WordPress in Gutenberg and we're passing back an object and this object can change essentially any attribute that exists for this component. And so in this case we only wanna change the title so we're passing in the title and kind of another ES6 shortcut here is the fact that normally when you're passing an object you would have the name of it and then the value of it so you have title, colon, title. Well, in ES6 if the name of the thing is also what the variable is named you could just put title there and it knows that title is title and it makes it even more succinct. So again, yeah, if you don't know ES6, ES6 it's something good to learn. So yeah, so that's how at a very basic level you can make these things editable and you can come up with a decent Gutenberg block. So there's more to it obviously but again I'm trying to make it as simple and straightforward as possible. And again there is gonna be some knowledge of JSX and some other things that will come into play but really once you start building and the key is to start building that way you're not trying to learn everything and then jump in. It's always better to come from a place of experience having hit a wall and then try to figure out how to go from there. So one of the best ways to do that too if you get stuck is there is a channel on Core related to the Core Editor where you can ask questions especially if you've got more advanced questions there's more advanced people in there who can answer your questions but even better is if you can ask your questions on a GitHub issue because everyone can see that and you can actually get answers when you Google. Or there's also a page where you can go to and you can actually submit a kind of a help request from the Gutenberg team as well but we'll have those in resources later. So yeah so we've created a save block we've created an edit block so now let's see what it looks like to kinda pull all that together and actually register this block with WordPress with Gutenberg. So here we are actually importing so we put the edit and save components into separate files one's called block edit and one's called block save.js and it's in a relative path to where we are now which is probably our block.js file which is where this is all coming together. So we're importing those two things and then we're gonna call this WordPress function register block type. So again this is actually this register block type function lives inside of one of these global libraries that WordPress provides. WP.blocks.registerblocktype is where that actually lives. So you'd wanna make sure that you get it from there. But so ultimately the first thing we're passing in here is the title for our block and again there's the namespace and then there's the block name. So what happens is when WordPress generates that class name it takes a slash out, adds a dash, prefixes it and there's your class name. But this is the internal name essentially just the same as if you use register post type. You have that internal name for your post type. This is the internal name for your block. So if you wanted to unregister a block you would use this name to unregister it. And then we also have, this is the basic skeleton of a block. So blocks gonna have a title which is essentially what the user sees when they go to add a block. They're gonna see that list of blocks in that block discovery section and they'll see it's a book. And then the icon here is essentially the slug for a dash icon in WordPress. So for those who've done anything with custom post types you know that you could create a menu attribute and you could pass a dash icon slug and then when you look at the admin you can see that icon in your next year post type in the admin. Same here if you take that slug of the class name from one of the dash icons that icon will show in your Gutenberg block. If you wanted to customize it you can use SVGs but I'm not getting into that at this point. So category is essentially Gutenberg uses categories or groupings essentially of blocks so when you go into that click that plus button and it shows you all the blocks it's actually gonna try to help you out and give you different groupings. It's gonna show you that there's some layout blocks there's some formatting blocks there's a bunch of embeds. So depending on where in that grouping your block needs to go you can assign a category and your block will show up in that specific section. So if you're creating some sort of an embed you'd wanna use embed here and that would go into that section. Since basically we're creating a block that is going to create a custom format or display for book information we're putting it in formatting. So this is and down at the bottom here you'll see edit and save and these are essentially where we're actually passing our React components for edit and save. And then we have attributes so attributes is essentially a JavaScript object that will allow you to define the strategy for pulling the data from the markup. So you've already created your markup you know what your markup looks like and because we're using BEM it actually makes it very easy. So for the title within the scope of the block itself we're going to find the WP block Gutenberg or WP block WP scholar Gutenberg double underscore title class name and that is the element that we're gonna be working with and the type of thing we wanna get is the text out of that and so the text that's inside that HTML is what's gonna populate our block so if it's been saved into the content this is how we extract it back out and put it into our JavaScript and display it to the user in an editable fashion and then as they edit it Gutenberg will update its internal state and when they hit save all that's saved into the content and then again when they come back to the post this runs and figures out what content needs to show in those blocks. So we have the title and we're doing the same thing for the description and author. So essentially that's the basics of registering your block type. This is a very different kind of approach than you've probably seen but just to kind of give you some ideas of different ways you can do it I have always liked putting components in their own files so being able to pull those in separately is important. So then the last step here is to actually make sure because everything we've done at this point it's in JavaScript, right? So no JavaScript is gonna load itself so we need to make sure that we load our JavaScript and of course we're probably gonna have some sort of CSS associated with this block so whatever those styles are we wanna pull those in. So we wanna register our script and we wanna register our style and notice that we're not using WP and Q we're using WP register because we're not actually trying to load it on every page we're just trying to tell WordPress that these files exist and can be loaded when they're ready or needed to be loaded which of course we don't need to load them unless we're actually in the Gutenberg editor or what not. So basically we do have some dependencies for our register script functionality so as I mentioned there's some globals that are available. So in order for those, so by default some of these are gonna be automatically loaded but just to be on the safe side always declare your dependencies if you actually use them so if you're dependent on that WP blocks for things like the register block type and for the rich text component that we would use for the editing experience you're gonna wanna make sure you include WP blocks as a dependency. Another one is the WP element library and that is essentially what allows you to render things. This is kind of happening behind the scenes technically so you probably didn't actually see or use that in this scenario. And then there's also a WP I18N which is an internationalization library. We didn't actually use it in the examples but it does exist. So ultimately what this does if anyone's familiar with the PHP functions for translation and WordPress which of course if you're writing good code hopefully use them all the time where you pass a text string and then you pass the text domain and then you can run some processes anytime you need a creative translation that will generate some files that will get loaded depending on the user's language and you can have this all show in Japanese or French or whatever or even Australian English if whatever. So that's a cool library and basically all that does is it adds that same functionality to JavaScript so you can just use those same functions in JavaScript and it will work. So then down at the very bottom you see that we're actually calling register block type in PHP. Well I thought we already did that in JavaScript. We did except this works just a little bit differently in that we're registering the block type in PHP for a few reasons. One we're gonna tell it what files need to load where and PHP is how we do that because obviously WordPress uses PHP. So the first thing you see there is style. So style is essentially the style sheet that we wanna load. So we've named the script and style sheet with the same handle because WordPress allows us to do that. So when we load our style we're just passing the handle of the style sheet that we want to load and that style is actually gonna load on the front end of WordPress and the back end of WordPress in the editor. So if you need to do any kind of styling this is how we make sure that what things look like on the front end also look the same in the back end. But it's important to be aware of the selectors and so BEM is a really good way to make sure that you're not styling other parts of the WordPress editor or WordPress admin screens accidentally because you're trying to select elements on the page. So you have to be real careful about that. So BEM is a good solution. Besides the fact that Gutenberg in the editor will sometimes add extra divs here and there so a little wrap pieces of your pieces inside of your block with extra divs so that the functionality works correctly. And so if you're completely dependent on the structure of your HTML to style it things are gonna break. So you wanna make sure that you actually target and try as much as you can to only style by those class names. So yeah, so when you use style here it's gonna load on the front and back end. If we did editor underscore style it would only load styles in the back end. So if you have a really complex block and you need a lot of custom styling to kinda make things look right in the editor you can do all that without actually adding any extra overhead on the front end. We could also call script instead of editor script and that would load our JavaScript on both the front and back end. But of course the JavaScript that we demoed today is only for the editing experience and has nothing to do with anything on the front end. So we don't need it loaded on the front end. So we're gonna use editor underscore script and actually have that load just in the editor. So if you wanna check out a working version of this block. Now granted actually this was for, I did this earlier I didn't do it exactly the way I did today but it still works and it still uses ES6. So you can play around with it. And if you, and that's the ES Next branch so that's all the JSX ES6. If you wanted to see the straight JavaScript vanilla JavaScript version where we're not actually doing any build processes and we're not doing any of that you can look at the master branch and all of that is just straight vanilla JavaScript. So yeah, so a quick overview there's a few different types of blocks. There's static blocks which aren't actually editable in which case you could have the same function or component for edit and save. So think a horizontal rule element. There's really not much you're gonna do with that necessarily. I mean you could add some features to it but at a basic level dumping an HR tag on a page it's pretty straightforward. Editable components you can actually edit the content. So think the text block you know you should be able to click in and edit the text. But then there's dynamic components where you're not actually editing the content but there's only settings that you can change. So for example if you wanted to show the top five latest posts in card format on your blog you might have a Gutenberg block where you would not actually set those manually but you would say oh I want the top five posts from this category and then it would automatically populate those when it rendered on the page. And in Gutenberg you can also create block templates which will allow you to dictate for a custom post type. Anytime a new entry for that custom post type is created what blocks should actually be already there for the user. And you can actually set placeholders, customized placeholders for whatever blocks you choose. And so when the editor hits add new instead of having to configure a bunch of meta boxes you can just create this array which dictates what components and these are all core components because again we have the namespace. So in my case it was WP Scholar in this case this is our core components so they start with core slash and then the name of the component. So we're taking an image it's over here on the left and over here on the right we have a heading and a paragraph. So just another way you could do books without actually having to create components at all. You could just do it as custom post type with a custom template. So here's a few of the resources for Gutenberg. The slides were actually tweeted at the beginning of this. So if you look on the hashtag for WCATL or at the WordCamp Atlanta Twitter that will be there and you can click on all these links but essentially we have the Gutenberg repository so if you haven't looked at the repository this is the source of all of the code and it's fun to click around and just explore. A lot of the internal WordPress libraries actually have readme's associated with them so when you click into those you can actually read more advanced documentation that you won't find anywhere else. Then we have the Gutenberg Handbook which is kind of a beginner level overview getting started creating blocks. They have the ES5 and ESNext versions of everything so you can click and see the differences. So another helpful tool if you're not familiar with ES6 you can start to get familiar with it and what it looks like in regular JavaScript and what it looks like in ES6. There's also a repository of Gutenberg components that have already been created by WordPress core as examples for you for when you're building your own blocks. So if you want to see how all of these things kind of come together that's a great place to start. And the tool that I use for creating my ES6 JSX Gutenblock was a tool called Create Gutenblock so if you've never used that before it's a great easy way to start so if you aren't familiar with Webpack you don't know how to configure things so that your ES6 is compiled into ES5 so it's browser safe. If you don't know how to do all this configuration you don't have to worry about it because it's already done. And then when you're ready to learn that you can eject and it'll all be there and you can change it at your will. And if you want to play around with React there's also something called Create React component. Is that right? No, Create React app. And so you can actually create React applications get familiar with React and then come over to Gutenberg and do Create Gutenblock and kind of see how React works by itself and how Gutenberg works. And then we have the coding guidelines as well that you can check out for Gutenberg. And if you want to learn more about JavaScript in React there's a great build 30 things in 30 days by Westboss with vanilla JavaScript. There's some free React and Redux courses on egghead.io which are really good. So if you're not familiar with React, they're completely free. Introducing JSX on the React documentation is also very good and because Gutenberg is built on top of React and it also uses Redux for data store management in the wp.data library or module. Installing the React developer tools and the React Redux tools is gonna give you an insider's view on what's actually happening when you do things inside of your browser in Gutenberg. So those will be very helpful if you learn to use those because in my opinion, if you're learning something new and you can't debug a problem then you're probably gonna take a lot longer to learn it and figure it out. So knowing how to debug is very important. So that is it and I think lunch is coming up and we're probably out of time for questions. But well, we got five minutes. So if anybody's got questions, feel free to ask. Otherwise you can sit, follow me around and I'll answer questions at lunch. Thank you.