 Thank you, Josh. Hi, everyone. So, yeah! The, um, yeah! Good work! Very sensitive dongle situation here. Too exciting. Hold on. Let's not get ahead of ourselves. Okay, so the goal of this talk is to bridge some of the high-level Things that Greg was talking about in the last one with Getting us prepared to start building actual blocks in the Next one. So, i'll show you a few Things here that are code and that are in the browser so you Could follow along. So it will start to have a Little bit more of that workshoppy feel, but feel free to just Sit back and watch as well. I'm going to cover a lot of Terms. If you haven't gotten into Gutenberg or haven't worked with react before, it's going To feel overwhelming, and that's fine. The idea is that you'll get overwhelmed with concepts now, And then when we start coding in this afternoon, they'll become More solidified. So if you have worked with react Or looked at Gutenberg before, this should start to feel like Second nature, some of these terms and things we'll talk about. But, again, i just want to reiterate, if it all just Starts feeling like a mass going through your head and Over it, don't worry. That's fine. We're going to get through it. Okay. So the first thing i want to talk about are javascript Libraries that are included with Gutenberg. And greg talked about them and we have things like react as well As a ton of other things at different levels. So we have to talk about these at a high level, and then we Have to look at how do we actually get them. Some of them are mpm packages, some of them are in global Scope, some of them we have to access different in the admin Editor than we would on the front end because of how things Are enqueued and registered. So that's important to talk about. And then the real heart of building blocks is this Javascript function called register block type. So if you've done any Gutenberg blocking, you've used this already. And it has a ton of different settings. So i'll just kind of get us familiar with some of these Settings, what it looks like in the user interface area to see These in action and then what it will begin to look like in Code so that you can kind of see, okay, when i see this on The front end, this is where this is going to be in the Code. When i see this happening, This is what's going to control that. There are also three different types of blocks. We have static ones, we have editable ones, and we have Dynamic ones. So it's important to differentiate The different types of these because they grow in complexity And what you have to do in order to make them work. So it's really important to understand, like, when i set up An editable, when i need attributes, when i set up a Dynamic one, i might need php rendering and why that is and What the use cases are for those. And then finally, there are just some little extra features That don't really fit into any other category nicely and We'll kind of close out with those. So starting off at the top with our javascript libraries Included with gutenberg. The first one we have is wp element. And wp element is a wrapper for react and react dom. So when we talk about the fact that wordpress has abstracted React, what that means is it basically took the react Library and normally when we would write react, do Something like react create element, now instead of saying That, we're going to say wp.element.create element. So all of the same names that you use in react, all of the Same functionality, it all works exactly the same, except Now you're going to refer to it as wp element instead of React or react dom. The benefit of this is that One, if you never learned react, you don't really need to Learn it specifically. You can kind of pick it up as it Goes by what wordpress makes available. The other nice thing is, although i wouldn't want to Make this work, if for some reason they decide not to use React anymore, they can switch it behind the scenes, like Switch to react or something else, or even patch react and do Something different, and the front-facing api never changes. So five years from now, three years from now, if they're Like, oh, we can't be doing this anymore or this doesn't Work, they can change the behind the scenes code and Nothing on our end breaks. So that's really important and A clever approach that if we had just loaded react like We do jQuery, we'd have a very different scenario and Some issues that come along with that. So then we have this library called wp blocks, and this is Kind of a weird one, but it has a bunch of little helper HTML components, and if you don't know what this word Components means in javascript, it's basically a Little block of code that you could reuse, like a button Component or a media uploader component or an image Component or paragraph component. Something that anytime you Wanted a button, you just use that same component no matter Where in the application it is. So you're reusing this little Bit of code, and everything in gudenberg that you see as part Of the default view, anywhere you click and you see this Little button or you see this panel pop up or you see this Functionality, you could use all of that in your own Blocks and in your own code as well. So because wordpress is built with this, when we go to Build our own blocks, it's super simple to kind of mimic And go beyond what the default ones are because we could Use all the same little components ui, the functionality And stuff in our own code. This blocks also has all of the Default blocks, so one of the important things that we'll do Is we'll look at how does wordpress build its paragraph Block, how does it build its code block, how does it build Its latest post block so that we can get a reference to that. And one of the coolest things in the history of javascript And wordpress, as far as i know, you can pretty much copy And paste anything that's in the core of gudenberg into Your own code and it will basically work, which is an Amazing experience and really follows this, like, react Reusable component architecture. Components is very similar to Blocks, except this is going to be much higher level things. So for example, in wpblocks we might find something like a Media upload button, but in components we might find a Generic tooltip. So whereas in blocks we might Find, what's another one in there, a way to put an Editable field so that you can edit a title or something. And in components we'd find a generic panel that could be used For anything. So components is really this High-level stuff that's used to build the entire interface Itself, and as gudenberg evolves beyond just being the Post and page editor and becomes bigger into the Customizer and into other areas as well, you'll see the Same components that they used to build everything Stored in there. So once again, we could Pull in anything. So if we want a tooltip, if we Want a panel, or if we want whatever it is that word press Is doing something else, it's probably going to be in one of These two libraries, and we can just pull it in and reuse it Super easily. The next one we have is, How's this pronounced? i, 18n, internationalization. Anyone? Someone? Internationalization. Okay. So this is basically, you've Seen this on the php side, and it's even simpler in JavaScript, but it's going to allow our strings of text in JavaScript to be translatable via the similar process that you Have for the way it's done in php right now. So that's important. Data, i don't, josh, Are we getting into data today? i don't know. Okay. So the great thing that Gudenberg does have is it has a way to manage data Store. So when you're getting into, Hey, what does this block have in memory at this Given point, and what does this post have in memory at this Point, and then what does this other plug have, or i want to Keep track of advanced state management. If this doesn't mean anything to you, don't worry, we won't get Into it today. But if you understand how Concepts like redux work and what solutions they might Solve, we have the exact same thing as pretty much everything Behind redux is made available with wp data. Now there are some specifics here where i'd say this is Probably a little bit more, the wp data to redux is Probably a little bit more different than the wp element to React and react dom just because there's some custom Functionality built out for dealing specific with word Press data and not everything is made available Completely interchangeably. There were some design Decisions made with how data is structured. Everything is public. Go javascript. Okay. So that's a little bit beyond us, But it's important to keep in mind because it's being Used internally and it's available for you to use in Your own blocks as well. But you really got to be Building something complex with multiple fields that's tracking A lot of data before that makes sense. And then finally we have packages. And these are, this is kind of a generic holder. They could include a lot of things, but the core difference Is going to be that these are available as npm packages. So we'll see if we go to npm.Js.org Slash wordpress, i believe that's url. Then you can see all of these packages. Everything else at wp, as we'll learn, is going to be made Available in global state. So it's available in wordpress Automatically for you and you don't have to import it. This has some pros and cons. It's really easy as a pro. A con is it makes testing hard and it makes it harder to Follow kind of the normal javascript workflow where you Aren't getting things from global state. You're importing them as packages and then using them Within your code there. But they are important to Make a lot of things, especially with setting up your Webpack and babel config, a lot simpler because we get to just Use whatever wordpress is using internally for Gutenberg for ours and it just all works. So this is an overview of the library and now what we want to Do is take a look briefly at it. So if you have a computer in front of you and you want to Go to github wordpress slash Gutenberg, i'm going to walk Through some of these really briefly, but i suggest at some Point you really take a half an hour, two hours to go through And look at all of these because once you learn how to Import a component you'll find this is a huge library of stuff I could reuse however i want in my own stuff. So the url is not what i have up. Github.com slash wordpress capitalized Gutenberg. Now the important thing to point out is that this we're Looking at it on github right now because when you download and Install the plugin you're getting a compiled version. So basically all of these folders are going to either be not Included in the final version or bundled down to just like a few Humongous files that are all minified and not readable. So if we want to look through the Gutenberg source code, You can't just open up the plugin that you're running. It's easier to go to a place like Gutenberg. Now this may be getting beyond most people, but because Gutenberg right now is being updated every other week, if you Want to get updates that haven't been officially pushed yet, you Could just download this version of it, put it in your plugins Folder and then run npm install and npm build and it will Build it out. So then you'll have access to All the source code as well as the latest version. If that doesn't make sense, don't worry. Okay, so let's come into our element folder first. So it's this one right here. And like i said, this is a Abstraction layer on top of react. So what we'll find soon is That if we go in here and we get access to this, which we'll Look at next, we will find everything in this that react Has. So has anybody played with react yet? Okay, cool. By the end of the day, you will Have and you'll see that parts of it are pretty simple And not too hard to pick up and that will allow us to Do quite a lot. So hopefully this abstraction Process makes sense. We're not really going to Go into all of it, but you could basically see they go in, Pull everything out of react, pull everything out of react Dom, and then go ahead and export everything with the Exact same name. So when we talk about like an Abstraction layer, in some ways it's that simple. Literally import stuff from react and then export it. So that's what we mean by an abstraction layer. Okay, so that's elements and we will use that anytime we're Building our blocks. Then we want to look at the Blocks and components section. We'll go into blocks first Because those are more specific just for building blocks. So things like an alignment toolbar, left, right, centered. All you got to do to have that is just include the Alignment toolbar. Boom, it's ready to go. Auto completers, those require a little bit more setup. Let's see if you want a little block icon, the color Palette. And you can see how these could be Used in inner blocks is going to be dealing with nested blocks If you want to set up something that goes inside of that. Inspector controls, if you've ever played with Gutenberg and you open up the side bar and it has a side Panel, all those inspector controls you can set up. And control, so media upload button, text editor, Plain text editor, url input, all of these should kind of Make sense and as you begin to look through it a bit more, it Will make more sense what it's doing. Then this library folder is really important and this one Stands out, it's quite different. So this structure inside Blocks, it's a bunch of helpful things and then this Folder library and then inside of library you have access to All of the core blocks. So when you open up Gutenberg and you click add a new block, these are the Ones you have access to. We've got a gallery block, HTML, image block, latest posts, paragraph. So this is the default block that is always shown and you can Come in and look at how it's built. So we're not really going to worry yourself too much about That now but it's really nice once you learn how these Blocks work to go look at the core ones and you can trust Me that it will be pretty similar to building your own Blocks copying their code. So as i said, components are Going to be a higher level up. So things like a check box Control, a generic button that can be used anywhere, date time, A drop zone, some higher order stuff we're going to avoid Now, navigation, like a generic notice, a generic panel, a Generic place over, pop over. You can see the difference Between these two. Block is going to be more blocky Specific component is for building the entire ui of Gutenberg itself. But any of these we can pull Into our code and use which makes that component architecture. The other one i wanted to point out was internationalization. And this is going to work kind of like this. So we do have a domain string. Has that been added? Cool. Okay. So this will work now Exactly the same as it did before in php. So if you've ever done underscore, underscore, Text, comma, and then like my plugin reference, whatever that Idea for your plugin is, that will allow you to translate. And our examples will show this later. So we don't have to worry about that too much at the moment. There is the data one. I'm not going to get into that Because we won't go too into that today. But it's going to do the same thing as reacted with, or As elemented with react, except it's going to pull in Redux here. So you can see it's pulling in Redux and then it's going to export out. Well, not exactly the same. It's a little bit more complex. So at this point, i think this is probably enough for us to do in Terms of looking through gudenburg core. But i suggest that you go back at some point and look through This even more, especially once you begin to pick up the Architectures of react, what you'll find, and again, this Is not common historically in wordpress javascript code, Is that, wow, this reads like a modern beautifully well Architected piece of application or software. And that's a great feeling to have. And it follows many of the Conventions that you would expect, given like the react Environment. So that's gudenburg core. The other one is wordpress.com Slash packages. And this is going to be Some of the helpful scripts that we'll see later, like Shortcut to setting up your babble configuration or What are some of the other ones that does object transform? What are the build process? Oh, yeah, the browser list support. We'll see some of these here. Ideally, hopefully, we get to A point where more and more is pulled out of gudenburg itself And put into packages, because what would be really great is To just be able to pull those packages in directly, as You'll see, working with the global scope is a little bit Different. We're going in that direction, But we're not there yet. So i wouldn't hold your breath Thinking that everything is going to be in a package right away, But that is kind of the direction it's going, right? Yeah. Cool. So... Excuse me? To match with what? Oh, it is. I don't know what to say about that. Okay. We'll come back. So many things that get me thinking. Okay. Okay. So that is the direction they're going. So instead, if you go to npmjs.com, as hopefully you've... If you've worked with javascript at some extent, You pulled things off of npm, there are some wordpress Repositories that allow you to pull in some stuff. Like, is the document ready to load? That's a small piece of code you reuse again and again. So instead of having to write that yourself, You could just use this little script, right? So stuff that is not tied into gudenburg core functionality Enough that it could be pulled out. If you're feeling good on core architecture, You could go back and revisit, right? Okay. So let's talk about how to access these. The first thing is that... We want to put the slides And presentation mode. All of these are going to be loaded in window.wp. So if you're not familiar with the basics of scoping in Javascript, if you declare a basic variable in javascript, It gets hoisted up into what's called the window object. So this is what allows you to write a variable in one Javascript file and then reference and use it in another. Because it's being taken out of that file, brought up to a higher Level that any javascript in that page can access, and then It has access to it. So what wordpress is doing As it's being built out is it's taking all of these libraries And attaching them to the window object underneath wp. So the easiest way to access all of this is just to type Window.wp.whatever and you get it. You could also drop window and you could just type wp. So here's how we're going to show this in practice. Basically, if you want to follow along, open up Gutenberg, whether you're editing a poster or a page, Open up the console and web developer, and then just type Wp element and hit return, and you're going to have Access to the entire react library there. You could also try it with blocks, components, i18, Wp data, and then you could drill down into every one of those. Remember how we saw blocks as, like, tons of things inside that? Then there's a library folder, and then there's all the stuff Inside of there as well. All of that is available in The global scope, which is kind of a frightening concept If you have some background with scoping and javascript. But at the same time, like, i support this, and i think It's a cool and easy approach, and as long as there isn't Overriding or anything too crazy going on, we should be Hopefully safe, right? And that's good enough for us. And then you can try it with just wp, and you'll find that Actually, wordpress is tacking on a ton of stuff into the global Scope that you may or may not know about that isn't even Gutenberg related or relates to other things. So let me just demo this real quick. And i encourage you, if you have wordpress set up and you Have the Gutenberg editor, go ahead and just open up We are live demo. Okay. Open up the editor. Come into the console. And first of all, the window Object is every possible thing that's stored at that highest Level. Then we have window.wp. We are testing dot element. So when i open this up and look At it, it's basically react. We've got our create element Right here. We've got our render method. We have fragments, children, all of the stuff that we Would expect to see. And i can drill down further Into that, wp.element.create element. And this is the same as writing react.create element. So i know this is super verbose, and we're going to look at ways To improve that. But this will give you Exactly what you would expect. Likewise, i'm just going to Shortcode it now. I'm just going to say window Was another one blocks. And then we have all of our Blocks. So let's say we wanted to Pull in a media upload, or rich text. That's more common. I could say, all right, give me access to my wp. Blocks, rich text. And now i have a rich text Component that's like a little whizzy wig editor that i Could drop into my block and it will automatically work and People will be able to edit their content. So this is how we get access to this. There's also wp. What were the other ones? All the components that we wanted to see listed. The buttons, the date picker, all that stuff. Everything we could access in this way. The last one i wanted to show you is if you look at wp Itself, okay, we've got backbone uploader, alley, Ajax, api, api request, a whole bunch of block stuff, Date, edit posts, emojis, heartbeat. There's a lot of stuff in the global scope right here. I haven't even looked through all of it. But this just shows that this is a pattern that has already Existed and we're just kind of extending and hooking into Something that is already there and working. Now what is interesting is if i go to the front end of my Site, so let's go view this post, and i type wp. Element, it's not there. So this is important. All of the react code and everything is being loaded by Word press in the admin area whenever it appears by default. If i go to a non-gutenberg page, it doesn't show up, right? Correct. And if i go to the front end, it's not there. If i look at, whoa, it's nothing. If i look at wp, in fact, Look how small it is on the front end. This creates a problem that josh will probably get to Towards the end of today, which is if you want to use All of this react architecture and use components on the Front end of your site, kind of outside of the normal block Architecture flow, you have to manually register them. They are available. There are limitations, but it Could also be done. Okay, so that's hopefully everybody Gets now. This thing is in the global scope. Hit wp. Whatever, and we have access to our content. We are going to do that. Cool. That's been the private bane and joy of josh and my life Lately. Yeah, he says he has An example in the front end, so we'll look at that. So, all right, so that's just typing in the console. Obviously, we're not going to build a plug-in in the console. We need to know how to get it into our code. So this is the right process that you would follow. You'd create a plug-in. Why? because blocks don't belong In themes. Why is that? Well, if you have content, if you have a block, it gets Saved into the content. And then you switch themes, The content no longer has that block associated with it. So you want your blocks to live on past theme changes. So while you can take most of the code we'll look at today and Throw it in your functions.php file and have a custom block for Your theme, once somebody migrates off of that, when they Try to edit that page, that block will no longer exist, And it's going to fall back to a default wizzy-wig editor In wordpress, which may be fine, but not ideal. So definitely first put it in a plug-in. And then in qjavascript, using in qblock editor assets, And brine will get more into this later. So i'll just say, like, anybody ever in qjavascript file before In a theme or a plug-in? right? exact same process. We just now have a new hook. And that hook will load anytime That the gunberg editor is loaded. So that helps us out there. And then we're going to do the Same process of wp.element in our code. So we're going to repeat the same thing, just rather than Using the console, we'll do it with an actual proper setup. So for this demo, and i think we're all using slightly Different development tools, i'm using local. And i'm going to come into my files here. Down into content plugins. And what i have done is Basically the repo that hopefully everybody has, did Everybody see the link, hopefully earlier today? There's a github repo for our course. He'll put it back up later, brine will. This entire repo, everything we're going to do today is one big Plug-in. So we just go in and say, hey, Turn off these blocks and show these ones instead. Turn off these blocks and show these ones instead. So i've just installed today's example thing as a plug-in. I'm going to open this up in my editor. And then the example i'm looking at is under snippets Library access. So this is just testing. This is a block just dealing with how to access these variables. And then later on you'll see there's a static one and a Static complete. So all of these are different blocks. The first thing we have to do is enqueue our javascript. Hold on one second. Is that better? Okay. So this should look familiar, right? We are basically enqueuing this block js file right here. And we're hooking into enqueue block editor assets. So that's just going to ensure that any time the gunberg editor Loads, it will also load my javascript. I'm going to skip over this because brine is going to get Into this in more depth. But hopefully this should look Similar to what you've seen before. You might be wondering what this is about. But i'll let brine handle that. And i just want to come Into the actual file itself. So if i did this right, let me Just uncomment this first one. If i did this right, when i open Up gunberg right now, it should load this message in the Console. So let's see if it happens. We're live coding so everything should work fine, right? Let's try that again. I see nothing. Okay. So the way this plugin was Designed is that in our core file, as i mentioned, there's a Bunch of different blocks and we're going to turn them on and off. So i'm just going to uncomment static complete index one. So this was commented for a later one. And i'm going to uncomment this one that i was just working on. And now, again, error, that's better. Okay. I'm not sure why that was. It's now saying library access testing so that i know that this has loaded. One thing about that i've noticed with consoling sometimes, if you Have preserve log turned off and i try to do this for some reason And maybe you can answer this, it clears your console. See how it's displayed there and then it erases it. If anybody knows why that is, i'd love to know. But in order to see it really works. What's that? Gremlins? Gremlins are in the thread. Okay. So it's working now. Let's try the next step. I should be able to just log window.wp Element or let's just shorten it to wp element. There we go. Okay. And so this is our wp element. This is react under the hood Exactly like we saw before when we logged it out in console. So all this is showing you is that the exact same thing is Going to work. You just enqueue your javascript. And then we could pull things down from wp element. So one pattern you might see to do this is something like this. We're inside of element. We want to have access to the Create element feature. And then we could use that to Create an element and log it out. This won't make sense till Much later. So let me pull this up next. So the problem is that we don't want to type window.wp. Element.createElement every time we want to create a ui Component. So there are some methods for Shortening that down. So in es5 one thing you could do Is say create element is equal to wp.Element.CreateElement or You could shorten it even further. Sometimes it's just called e. So you could say var e equals. Or more likely in our examples We're going to be using the es6 approach. So you could use object deconstruction where this Code here, the second line, will go into blocks, look for Something called create element, and then pull it out as a Variable name, create element. So in both of these examples, They're doing the exact same thing. We now have access to this Function called create element. So this is the format. This is what's going to be at the top of almost all of your Block pages at some level, something like this. Okay. What do we need? Do i need to pull in All of element? Do i need to pull in a certain block? Do i need to pull in a certain component? And if we go To skip forward to later today, fingers crossed. I'm pulling up a file that works. But it's done differently. Hold on. Not import examples. Yeah, these are all imports. J.P., man. It's all good. Hold on. Let's try it this way. Brian's got me. I know it. Okay. So here we go. Right? So this is renaming it to something shorter if we wanted To use the translation feature. We can just rename it to underscore. If we want to use create element, we rename it to l. Now, what josh goes ballistic with here later is we're going To look at a webpack config that will allow us to actually Run import instead of equals or setting up a const. And technically it's the exact same thing behind the scenes. This is just a like syntactical sugar way of writing it. So that it looks like you're importing, even though it's still In global scope, right? And referencing. Yeah, it transforms. Okay. So again, just making it a little bit prettier and following conventions. But at the basic level, i just want to point out again that At the top of pretty much every block, we're going to be like, Okay, we need this, this, and this. And this is the general format for how that's going to be done. All right. We are getting close to lunch. I'm going to talk for about 10, 15 more minutes here, and then We will transition out. So now we're getting into, Like i said, the heart of the matter. So register block type is going to be the javascript function That we use that actually creates the block. And some of you are asking really good questions like, Can i control at a block level what users have permission to this? And the reason the answer is kind of no, is that this Is all done on the javascript side. So at a server level, at a php level, it doesn't know necessarily Always what blocks are set up or what all the configurations of Them are. Now, the weird thing is, Is that go word press, there is a php version of this and a Javascript version of this. So you could technically register Your block completely on the javascript side. And does it do something php down there somewhere to Eventually create it on the server or is it just staying? Yeah, okay. So you could create it entirely With javascript and behind the scenes it's going to run some php To actually register the block. You could also register the Block with php and then add a few things in the javascript. And the direction they're going, although it hasn't gotten Here completely yet, is eventually this register block Type will be a php function. And the reason for this is That if you register at the php level, you get access to doing A lot more checks like user permissions, finding out what Block is loading, finding out if it needs to have certain things Set to it, that you can't do with javascript because it Doesn't exist in that server world where you can check all of This. So even if we could, like, Set a state for what permission the user has, it's still Like that quasi-dangerous world of doing all of the Verification in pure javascript, right? So register block type will evolve, but right now what we're Going to show you will work. So create the custom blocks. It has a bunch of different settings. I'm not going to show All of them in depth, but i'm just going to kind of ease Us into this, because again, brian is going to pick up and Go into this in depth. So every block has a name, An icon, and a category. And if we open up a block, So this is the code block in Gutenberg, the name is code, The icon is that little icon, and the category is formatting. So if you scroll through blocks, you'll see some different ones. You'll see, like, common blocks, categories, widgets, Embeds are some other ones. And these are defined. And as far as i know, you cannot edit these, and it's not Going to be editable. What's that? Oh, it's getting removed. Never mind anything i said. Okay, great. Okay, so right now, Categories are defined. There's only, like, five of them, i think. Layouts another one, but it's going to be expanded so That you can set up custom ones, which is good to hear. Okay, but do you see what i'm saying? We have these. This is what it looks like on the front end. And then from a code perspective, this is what it looks like. So, again, we haven't looked at the code. This doesn't all need to make sense. But it should make sense that title is named code. Icon is this reference here. Category is set to formatting. So one thing my code's outdated, because the underscore Didn't use to need a namespace with it. It does now. So got to fix that. But this isn't too difficult to figure out. It's basically setting properties, right? And it's just a little string of text here and there. Some icons we have available to us built in, but you could Also pass a custom svg to icon and give it whatever icon You want. So that's just an example Of name icon category. Now it has some other settings. Two other really important settings are the edit setting And the save setting. And the edit setting creates all The functionality that lets you edit a block. So this, if we were creating a map block, which would be a Sweet thing to do, then you would create some sort of Editable area where they could put in an address, right? And then it would display the map itself. So that part that lets you edit the address and determine Like, hey, do i show the map while i'm editing? Or do they have to click out of the block? And then that shows the map. Or, you know, how am i doing this? How is this, how is the editing interface going to work? You control all of that. And you're writing it with pure JavaScript and you're writing it with react, the react Abstraction and probably jsx as we'll move into. So this is really important that, like, by default, we could Set up components and add them and build the edit Functionality easily, but we don't just create a block And wordpress takes care of how the editing works. We have to code it ourselves. So it's kind of important, and I think kind of fun, but it can be a little bit of work and Something we really need, we'll pay a lot of attention today On the editing setting. Then the other one is saved. So if you don't understand how this works yet, when you Have ten different blocks in, when you have ten different Fields in, like, advanced custom fields, all of those get Saved as different meta points, and then in your template, you Have ten different references to the field, like, put the price Here, put the event location here, put this here, right? Can you imagine this kind of setup? this is a pretty common Workflow with working with advanced custom fields. When you work with Gutenberg, you have twenty blocks and They all get saved down to the underscore content. So once they're hard coded in there, that's just how They're going to look on the front end of the site. And so we have to determine how they're going to be saved. So you could be editing a block, and it could look completely Different during the edit experience than what it looks like When it's saved out into the actual content area. And usually we write our saved stuff purely with javascript. However, when i talk about dynamic blocks in a little bit, You'll see that sometimes we have to render them with php. And sometimes both. So what does this look like? Okay. So here's the same code block. When we edit the code, you can't see it, but i've clicked in There, and we have an editable field, right, called rich text Under the layer or something, a code or html. One of the default components, and you just put it there, And it works. So we don't have to do too Much to make that editable. But on the front end side, We have to specify, hey, i want to have a pre-tag with code Inside, and then whatever they make editable, put that inside There and then close that pre-tag. So we're determining what it Looks like. So this would allow us to Maybe up there in that example, we don't have a pre-tag. Maybe it's just a code tag that is editable inside of it. Maybe it's a paragraph tag in one place and code in the other. Now, the general principle with goonberg is make your Back-end editing experience look as close to the front end The way it's going to be saved as possible. So generally, you're trying to pretty much mimic the same thing, But there are times where in order to edit a block, it might Get way more complex than how it's going to look on the Front end, or it might look different depending on whether That's block is showing up in their post or page or a Custom post type, right. So the front-end styling may Change in certain contexts. But in general, these are two Different things we have to do. We have to write the Post script to allow you to edit the code, and then we have to Determine how it's going to be saved as content. This is the stuff that if it's a blur to you and not making Any sense, don't worry. All you need to remember is There's something called edit and save, and brian and josh Will explain all of it later in more depth. Thanks, guys. Okay. Love my job here. They gave me the easy part. This is what it looks like in code. So this is taking from This is literally the code block. So this is core Gutenberg literally copied or screenshoted, not even copied And paste. This is out of how they Build the editor, or how they build the code editor. So notice that when you're editing it, they call this Thing called plain text. It has a few configurations to It, and that determines the editing experience. And then when it goes to be saved, notice that we're Going to pre-code and then putting in the content. So not all of this should make total sense yet, but what the Thing you really need to know at this point is that we're going To code something called edit, and we're going to code Something called save, and they're going to control the Edit experience and what it's saved to. Now let's talk about potentially one of the most tricky and Complex things when you're first getting started with Register block type, and that's attributes. So attributes are basically you can think of them like The variables, and any time you have data in a block that's Going to be changing, it has to be defined as an attribute so That it can be tracked both in memory and when stuff is saved At the database. So let me give you a few Examples. In a regular paragraph Tag block, the content that you're editing is saved as an Attribute, right, because it's changing. So at some point somebody is going to have to say, okay, I need to have reference to whatever the latest version of That block is, and the way that we do that is by referencing This thing called attribute. Now, some blocks, like this is a Quote block, it has two different attributes because it has The value of the quote itself, and then it has the value of This person, and these are two different pieces of data. It's not saved as one, so you'd set up two attributes. If you were uploading an image, you could have a bunch of Attributes, you could have the id of the image be one piece Of data that you could save, you could have a url to the image Be one, the alt text, the title text, a caption Potentially, right, you could really begin to have in a very Small piece of code quite a lot of attributes. And here's what a very basic one looks like. This will be the first one you write today. We do a little message block, and we're going to define it As a message. There's a little bit of Difference. I'm going to let brian explain this Because the source stuff gets a little confusing, but at a basic Level, you can kind of think of it like type setting, like, hey, This is going to be a number, or this is going to be some Text, or this is going to be a bunch of react components. You're just kind of telling react what it's going to be, And there are some checks, but not a ton, right? It's a little flexible, perfect. Okay. So this will be the first one you write. And then here are what some ones look like for the default Image block. So as i mentioned, there could be A bunch of them. So we've got a url to the image. We've got the alt. We've got the caption. And like i said, attributes took me a while to kind of wrap My head around and really figure out how they work, but They don't come in until we really start to have a ton of Editable data. The last thing i'll say is that Attributes can also be data that you're not editing Directly as part of the block, but might be a setting for The block. Like, let's say that we have a block That has a bunch of fields within it, and we want to toggle on And off a certain thing. Like, maybe using a map Example, which would be a great example if someone did, You know, and it had a toggle on and off, or like, do we Want it to be satellite view, or do we want it to be Street view, right? And we had a setting that just Toggled on satellite or street view, right? So that's not a piece of, like, data someone's typing and Editing, but it's a piece of thing we'd like to have in memory Because when we go to display the block, we want to know Which one do they have toggled on or off. So you could also think of it as kind of meta information About your block. These are almost all of The different settings. So i talked about name and icon. We also have descriptions for blocks. We didn't talk about Keywords or supports. I talked a little bit about attributes. Transforms are really interesting. If you go into a block, Or if you go into wordpress and you drag an image into Gutenberg, it will display an image block. But you have an option to click on that image block and say Transform this into a gallery block, and it will Automatically take that block, pass it through something Called a transforms process, and then convert it into a Gallery block, and then it becomes a gallery block. So certain blocks have transforms, and they make sense, Right? Let's say we have a paragraph and we want to Transform it into a heading. Let's say we have a paragraph and Maybe we want to transform it into a list or a list that we Want to transform back. You probably wouldn't have a Transform going from a code block to a twitter in bed To, i don't know, to a random button, right? So transforms don't always make sense, but for some things They do, and core does quite a lot of them. So not something we're going to code today, but does exist. And it saves. And then finally, all of this, As you saw, are just properties and javascripts. So you could write quite a lot of your own javascript, just Like in react, you could implement a lot of javascript all Over the place. We have this flexibility with Our blocks as well. So we could begin to code Custom methods that my block could do, that no other Block could do, because it's doing api requests, and it's Getting cool stuff from here, and then it's checking to See if this is the case or that is the case. So we're not locked into just these few things. All right. Coming close to the end. Doing good on time. Okay. There are three different types of blocks. We have static blocks, or editable blocks, and dynamic Blocks. So a static block, you cannot edit. And this is going to be the first block that we build. It's also the least helpful block you could build, because That text, i'm clicked in there, and you can't tell, But like, i can't edit any of that, right? So this might be something, maybe a banner that is just Consistent across the site. You want to add a new Marketing banner, and it's just this picture that you don't Want anybody to have access to change, right? That would be an example of one. It's hard to come up with good Examples of static blocks, because you want to edit it, right? So the next kind of block we have is an editable one, and The paragraph is a great example of this. If you click into a paragraph text, you could edit it. Most blocks fall into the editable category. Images, code blocks, list blocks, heading blocks, Paragraph blocks, anything that you can click in and edit, we Call an editable one. Now, the important thing is that When you edit an editable block, when you click save, it takes Everything you coded, and it saves it as part of the Content. Dynamic blocks don't save Any content with the javascript. All they save is a Bunch of settings. So the most common example Use for this is the latest posts. If we edit a block and we insert, or if we're editing a page And we want the latest post to be halfway down in our page, right? So we throw in that block and we hit save. At that moment of saving, what were our latest posts? Whatever we saved at that moment, right? So if we were using an editable or a static block in that Case, ten days from now, the latest post would be Whatever they were ten days ago because that data never Got updated. It was saved as hard coded In html and there it stays. So what dynamic blocks do is A little bit different. Dynamic blocks are going to Allow you to say, hey, just get the latest post. So we're going to save a setting called get the Latest post, and then we're actually going to use php to At the time of render, whether it's an rss request or Whether it's a page request, go ahead and build out the Content that you want on the fly at the very last Moment possible and then display that. So if you leave your page unrefreshed for ten days, it's Not going to refresh itself, but whenever it refreshes, it will Get the latest version of whatever that is. So in the database itself, if you look at in the content for A dynamic block, it's just this html comment with an empty Div, right? There's nothing in there until the page is Actually rendered, then you see stuff come out, right? Now we have explored some ways to do this differently with JavaScript because one of the weird things in this scenario is That then you're writing your editable part of your block Code in javascript, but then to display anything you need to Write in php, so you're switching back to php, so we're in This weird environment where like, oh, yeah, to edit it all And to display what it looks like in gunberg, so to show how My latest three posts are going to look like, okay, i'll Call them, okay, all this here to display each of these and To toggle between them, this is all done in javascript. However, if i view the post, the actual code for rendering it Here is all done in php. If i add a quote, the code i Used to create this to be editable is using javascript And the code that i used to create this to be displayed This way is also javascript, so i'm still in the same file, I'm still in the same process, so this is going to get a little Confusing, but josh is going to do a great job walking you Through it, so it should all make sense. Again, my job was to come up here and be like, blur, blur, Words, words, concepts, go, and then you code and you're Like, oh, this isn't the first time today i heard Something about attributes, i'm not going to lose my mind Because, yeah, i've heard that before. I know what you're talking about, right. Okay, last section, extra block features, these are just Some things that i couldn't really figure out where to put Anywhere else, but i wanted to make sure that we talked about Before you started coding your own blocks, and we're down to The last minute or two here. When you're editing a block in Gutenberg, it has a selected state and an unselected state. So by default, the paragraph block looks like that. It's smooth, it's seamless. There's no interface around it. There's no borders, there's no toolbars. And then once we hover over it or click into it, then we Get what's called a selected state. In our code, although it's changing how we do this, you have To say if my block is selected, then do the following, and if It's not selected, then do the following. So we have to write that conditional statement in there. So this is something we just want to know about in advance, So you'll be using is selected, or not the higher order Function, or i think we're using is selected. It's changing so fast. I don't know what you're going to do this afternoon. But you'll find a way to do is selected. The other important thing to know about are what are called formatting Toolbars. So these are controls within the Block itself that appear right over it that have simple formatting. But it's really important to follow this rule that these are Formatting toolbars, because we also have something called the Inspector toolbar. So formatting toolbars are Going to be for controlling how that content should look. So anything that you would expect to go along with the Big experience, like these make sense. If you had an image, you might still have alignment, or full Align, or full width, like those sort of things make sense. When you get into settings, like if we were using the map Example again, and we're like, hey, should this have a Satellite view or a street view? these do not go here. Instead, all settings should go in what's referred to as the Inspector toolbar. So if we click on the three dots And then click, now it's referred to as advanced settings, This sidebar opens up, and then we have a ton of settings. So hopefully you've already seen this feature. This is a component called Inspector, no, Inspector Controls. And all of these are little Components. So we can super e, okay, we're good. I love that plug-in. These are super easy to do. So you might think, oh man, all the complexity to go Into building these sections. No, you write Inspector Control, and then you write, like, tech selector, radio selector, And it's super easy to config and set up. So just remember the design architecture for blocks is you Want to keep them looking as much like they're going to look On the front end as possible, which means not putting a ton Of settings or, like, i know people are going to do it. They're going to add their own, like, custom toolbar, toolbar On top, right? Or they're going to have something fly Out to the side of it that then isn't accessible on mobile. And, like, this is going to happen in all these things. Just remember, follow the conventions. Inspector toolbar, the, that's the last thing. I just got cam on the time. So you can save all of your Questions for brian and josh after lunch. And, yeah, cool. Yes! One applause.