 Thanks Joe. You have to code a custom Gutenberg block for a client. Unfortunately, you can't use the existing blocks. It has to have custom markup around it and custom styling, so you're going to be writing your own block. Sounds exciting. There's only one problem. You don't know much about React, which is the place I was in an earlier part of this year. Should you learn a lot about it first? You might take an online course. You might try to learn a lot about the background of how React works, Redux, try to learn a lot about Gutenberg, check out several plugins, then maybe you can get started eventually on your own block. So if you're thinking about how much React you should learn before you get started developing, I think you should learn as little as possible. You'll learn what you need to do this as you go, but we're going to talk about the basics that you'll need to code your first block. It'll be best practice. It won't be sloppy code, but we're going to get started right away instead of waiting until you know all the internals of this and you're really confident with how React and Gutenberg work. It's easy to get caught up in the detail sometimes of really diving into everything. Sometimes I tend to procrastinate by doing a lot of research, taking online courses, but I think it's good to dive into it right away. So let's do that. We'll talk about some of the main concepts in this. This is definitely not going to give you everything you need about it, but it'll give you what you need to get started. JSX is the main construct in React as you might be familiar with. It's very similar to HTML. You can think of it like HTML with some custom props and handlers. As you can see, it looks very similar. You have the HTML on the top, and it has properties in JSX, as you can see in the bottom, just like HTML does. One of the main differences there is that it can have dynamic properties, properties that have JavaScript. So the basic one is the class. You have just a string of my class. You'll see that it appears just like usual in HTML, but you also have that property of onClick, and that's evaluating JavaScript inside of that. It might look a little strange. I remember seeing that arrow function looked really weird to me when I first looked at something like this, but we'll talk about some of the syntax and get you what you need to really get started with this with best practice code. You'll often see JSX wrapped in parentheses. This tripped me up the first time I saw it. It's pretty confusing, but all this is is returning the JSX, and that's just because in JavaScript the way it works is if you return something but there's nothing on the line where you have a return, it actually won't return anything. So it's essentially a wrapper for this. One exception that you might see for this is if you're just returning a single line of JSX, if this were just to be return, openDiv, closeDiv, and then semicolon, it's a lot simpler. You don't really need to wrap it in parentheses, but that's pretty similar. Sometimes you'll see this being wrapped in brackets also. It looks a little confusing, but you'll see it wrapped in openClosingBracket and then openClosingBracket with a slash on the very bottom. But that's pretty much the same thing. It's just a wrapper for all of it. We looked at the props, just like how HTML has props, and the nice thing at this is that these are available inside the rendering function. So there are two parts of JSX. You have the actual syntax of it, like on the top, and then all of these components, just like HTML elements there, will have a rendering function or class, which is really a function also. And then that becomes available inside the function. We have that prop of onClick, and then we'll see that. So that's the typical syntax you'll see for react functions. You'll have a capital name. It's usually capital and then camelCase. I think there's another word for that also. But you have the props available in that. And then props.onClick will be your onClick handler. And we'll take a look at a little bit of that syntax. It might look a little bit strange, the brackets around it. Also, this is the function going over most of what we talked about before. You'll have the edit function, and then it's actually returning the JSX inside it. We have onClick that's available. It's a pretty basic example, so it's just passing it straight to that. But you'll notice that the return is wrapped in parentheses. And it's a pretty basic example. This might be something that you would use if you're registering a lock. This could be your edit function. And this is what will appear in the Gutenberg editor as opposed to the frontends. Now, this is another way of writing the exact same thing, really. You can, as an alternative, have a class. And this is the edit function. You can see in that render method, that's doing the same thing. It's basically the same as the return line right there. You have the render method, and then you just return that same JSX. This is a pretty unique thing to ES6. And it's actually not necessary to use classes like this unless you're using state. So for your first block, you might not be using this. But as you're looking at Gutenberg blocks, you should be aware of what this works like and how this works. You'll sometimes have more methods. For example, there's the render method here. And you could have other ones for all the handlers. But it's a nice construct. It's sort of like a PHP class or a class in any other OOP language. But this is pretty useful. The case where you'll definitely need to use a class like this is if you're using the state of the component. And don't get too worried about what that means right now. But one case where you might need to use state is if you're fetching from an API. For example, in a plugin, we were fetching the users and making a request. So we set the state when the request came back so we knew when to display something. But a lot of times for pretty basic blocks, you won't be needing to handle the state. So just be aware that this class exists. And those are some cases that you'll need it. Like if you're using state or if you're using API calls with that. This is another strange part of ES6. And it's much more common here to see arrow functions than the previous function syntax. At the bottom, you see something from ES5, which is older, more traditional JavaScript. And there are, of course, many ways to write function declarations. But one of them is just a plain function, myfunk. And it's pretty rare to see that in Gutenberg type code. There's nothing wrong with it, actually, other than this. But typically, we'll use ES6 and plugins that extend Gutenberg or write custom blocks. So you see at the top, the main difference is the fat arrow. And it was really confusing the first several times I saw that how the fat arrow works. But it's just shorthands. And it's nice to even see the parameter of slides. It's not even necessary to wrap that in parentheses for it to work. Typically, you'll see it wraps in parentheses, but it'll still evaluate the same if it's just a single parenthesis. And the nice thing about arrow functions is that they make it much easier to use with event handlers. Similarly, you can just have a single line return. It's not too important to know this. It can be confusing if you see this in a block. But if you see slides as the parameter, it's pretty straightforward. And then there actually is no return statement. So it's just returning slides.intro first, and you don't have to write return. So it's a little bit easier if you have something to put that on one line. Also, this is a nice change in ES6, the more modern implementation of or specification of JavaScript. And that usually we'll use const, not ver. It was really used to writing this, so this is a strange change to make. But it's pretty rare to see ver declarations in plugins extending Gutenberg or writing custom blocks. We typically use const unless you can't. We'll talk about some cases where you can't. But typically use that. And the only case where you can't usually is if you need to reassign the value to something. And in that case, we'll use let at the bottom. So here's an example of where you might need to use let. And typically it'll be if you have to reassign something via conditional or something like that. In const, syntax, this won't allow that. You'll get a browser error or a console error in the browser from doing this. But it's nice using const. It will enforce that you don't have unexpected changes to the values. This is another strange thing that you'll see. You don't absolutely have to do this, but this will make your code a lot cleaner and more best practice. Remember looking back at code I wrote without using this and it looks pretty strange. But this is another quirk of ES6 and that's destructuring. So at the top, sort of traditional JavaScript, you just access objects, values by props.myprop, props.otherprop. But here's a shorthand alternative. And it looks a little strange, but in brackets, you can just write the const values that you once assigned. So we just pull out my prop and other prop from this. Here's an example of where it becomes more useful. The previous one doesn't really make much of a difference, although it's much more common to see the bottom example. But as you're getting more props that you're pulling out of that object, it makes a lot more sense to just do this. It's a lot cleaner. Another benefit of this is that if it doesn't exist, I believe it'll just be undefined, so you won't be getting errors. This is another quirk of ES6. It's not absolutely necessary to use this. Most of the time you can get away without using it, but it's good to be aware of more or less how this works. And this is the spread operator. You can see in the third line, you have dot, dot, dot, my default. And it's another pretty strange thing that it takes me a while to understand. And essentially it takes the contents of an object or array and strips them from that and puts them in another context. In this example, in the third line with my default, it's not copying the contents of it within an object. It's not copying the actual object. It's just copying the contents. And a common place where you might use this is with defaults. If you have some defaults at the beginning, but then if you see in that example of the fourth line at the top, you want to possibly override the defaults. And it's a little bit complex. It took me a while to understand how this works. And it's not absolutely necessary to understand all of this right away, but you're going to see this in the components that you're looking at and as you're looking at Gutenberg. So it's good to be at least aware of this. This is a really important thing when you're learning a new framework or a new language. It's easy to waste a lot of time when something's going wrong, but you don't really know what's happening. So you might set a break point, let's say you put debugger in the code and it'll stop the execution in the browser and you can debug through the dev tools in the browser. That's not bad, but it's going to be a little bit harder because JSX is compiled. So you'll see sort of a messy compiled version and it's going to be really hard to debug this. It's something that will waste 30 minutes here and hour there debugging, but it really adds up. I think it's worth taking the time at the beginning to get a setup like this and it will make it a lot easier as you're developing for this to be able to step through. Otherwise, you're really flying blind. I've spent a lot of time, unfortunately, flying blind, not debugging in JavaScript or PHP before, but it really helps to get something like this set up. I've been using VS code for JavaScript development, which is really popular and I've used some other IDEs, but that's worked really well with setting up break points. It's going to take time. It took me a day or two struggling with this to get it up and running, but there are some good guides out there. So that link is to one of my two videos, but of course that's not the only resource. You can search for this also, but take the time to get a good debugging setup. If you can see, there's that break point in the right of the image where it's actually stopped there, you can step through and debug, find all the values and scope, and it's going to be much easier when you think it's actually setting an attribute, but something's going wrong and you're kind of wondering what's happening. So invest the time if you can up front to get something like this going. It's going to seem like a waste of time and burdensome as you're doing it, but it's a really good investment. Let's take a look at an example block and apply what we've been talking about with this. This would be destination block. It will have the name of the destination and photo of it. You might think we could just use existing blocks for this, but it needs to be wrapped in markup so it appears with the same styling every time a client adds something like this. It's not possible to simply write using existing blocks. First, we'll get a build setup running and luckily Gutenberg has a really nice setup that you can use with this already and I'd recommend using that. You could even change some of the configurations with this. You might be familiar with this already, but JSX will not render in a browser by itself. So if you take some of the examples that we were looking at, for example, this syntax, if you copied that return statement, that would not run in a browser. It's actually a wrapper for functions, creating the elements. So what we need to do is have some way to build that. WordPress, like I mentioned, has a really good setup for that and I'd recommend using that. At the bottom is a link to pull request that I created. Of course, there are other resources and just that, but that's an example of a very basic thing. You can just take a look at the diff and you can apply that to your own plugin and it has a few links there to the documentation, but that'll get you up and running and there are also several other things you can use from that. You can use the ESLint setting or a configuration from that same package. Next, we're going to use existing components as much as possible. Just like any part of development, we'll try to avoid rolling our own whenever possible. Gutenberg has a lot of great components that you can use for this. In this case, we'll use the rich text component, but you can find them just looking through the repo as you very well could be aware of in Gutenberg slash packages slash components. You can look through all of them there. A lot of times, I'll just look through existing blocks. If I have something that I need, it's very common that you'll see something that already exists in a block. Maybe you need it in your block or you need something a little bit different, but it's pretty rare you have to completely write your own component. In some cases, you can take inspiration from an existing component. For example, we had to do something using an input that's searched for users and it didn't exactly exist as we needed it in Gutenberg, but we modified the URL input component and essentially forked that, but changed about half of it. Of course, that's an extreme example of forking, but a lot of times it's best to look at the existing components. You'll at the very least usually find inspiration for what you need from there. Then you can see here we have destructuring. We'll wrap that in the brackets. We'll have the rich text component. It's coming from wp.blockeditor. You'll see some different syntax. It's fine to do this like import rich text from at WordPress slash block editor. That works just as well, but you won't need to add quite as much to package.json. You see at the bottom, just like we talked about with destructuring, you have that rich text constant that just gets assigned from that. The next step is we'll begin the edit function just like we looked at before. We'll actually use this as part of the function call to register a black. I won't go over all of the internals of how you're going to register the black, but there's the function you could be aware of it, register black type, which will add your black. Then one of the arguments that you can add to or that would be a property that you can add to the object is the edit function. What we're going to do is construct that edit function, and that is what's going to appear in the black editor. This is pretty similar just to what you saw before. We'll have as a parameter to that, props, just like any other component in React. From that, we can get the attributes. The attributes are what are stored in the database in the actual post. We also have attributes with properties. For example, we'll store properties for this. We talked about we need the destination photo and the name. We'll store those in source for that photo and for the destination name. You can see it's double destructuring there. We're first getting attributes and then separating that out. There's a shorthand for that that you can use also, but that'll do the trick for this example. You also see that edit is capitalized here, which is the convention for all of these. Next, we'll return the JSX from edit. Just like we looked at before, this is the important part. We're going to return that rich text component. Of course, there's more work to do at the bottom. But you'll see the handler, just like we looked at before, on change. It's a pretty common convention when we have properties to have them camel case. Like we looked at, instead of seeing class, you'll typically see class name. Instead of seeing click or something like that, you'll see on click with camel case with that C beam capitalized. That's a handler for clicking on this in this case. It's a very, very simplified version of this. The real version would have more properties, of course. But we'll look at how that works. That's going to handle changing an attribute. We're going to save something here to the database. We'll get the new value, of course, as the parameter here. Interestingly, you don't even have to wrap new value in the parentheses, but it's typical to see that. Next, we'll actually save that in the attributes. We've got the attributes above, and then we'll just add that as the new value. It's a very simplified version. You might want to do more logic in the real one. And then we'll finally call set attributes, and that's the one that saves the value to the database. And that's another case of where having a good debugging setup from the beginning is going to be really helpful. For example, let's say it's not saving. If you don't have a debugging setup in your IDE, like VS Code or whatever you'd like to use, it's going to be a lot harder doing that in the browser. I've spent way too much time stepping through break points in the browser. Of course, at the bottom of this, we can add more components. The next step here is we're going to move this to a separate file. This isn't absolutely necessary, but as your edit component is getting to 80, 100 lines, a lot of times it's good to sort it out, so it's better to organize. It's a little easier to understand, and it'll use ES6 modules here. And you'll notice at the bottom we have an export statement. Typically you'll want to use defaults if you just have one thing to export. Here we're just going to export the edit function. And then back in that main file where we could call something like register black type. We're actually registering it. We're going to import that. And because we use default, we can just use a different name for it. You can name it whatever you want here. If we didn't use default, it would have to be the name that was exported. So import edit from edit, pretty straightforward. And then we'll register that. And that's the syntax. These are at typically the same level in the directory. You'll have your index and you'll have your edit. And that's the syntax to just get it from the same level. It'll just go from the same level to the same level. And that's the syntax to pass that to register black type. You'll notice there that it doesn't even look like edit colon edit. It actually evaluates it that way. You don't have to write that. Also, there are several things you don't need to know to get started. It doesn't mean you shouldn't eventually learn these. But don't worry about diving too deep into the details of some of these, especially when it comes to the syntax. Things like WP data that selects you typically won't need at the beginning or dispatch. And high-order components usually won't be too necessary. Don't get too into something like with selects or compose right away unless you find limitation where you'll actually need these. This will get you started with learning what you need in JavaScript. You'll be writing best practice code, dirty code to a client, but you'll actually get started and you'll learn most of what you need along the way. But if you've been thinking about extending Gutenberg, writing your own black, there's actually no need to wait to do that if you would like to. You don't need to know too much about the fundamentals of React or how everything works together. A lot of times it's better and just more fun to get started with it. Thank you. And are there any questions left? All right, so we've got some time for questions. Just a reminder if this is your first time asking a question, that we do ask you to wait until the microphone gets to you just so that we can make sure it gets picked up on the recording. Do we have anyone who would like to start off? Ryan with a question. Come on, don't be shy. Yes, I'm in the middle. I love your bravery, sir. Thanks for your talk, Ryan. You were wasting time doing online courses and tutorials before you started and obviously did your homework on ES6. What can you recommend for jumping into ES6 and React? Westboss is a great online course. I was just watching some more of that yesterday. ES6 for everyone is a great one. That was really useful. Any of Zach Gordon's courses are really great for this. But those are really useful and I don't mean to say that you shouldn't take these. I've gotten a lot out of them and it really helps to learn all of this. Actually, some things I just couldn't do it all without those courses. Those are some of the main ones I would start with. Maybe you've worked on that already. ES6 for everyone. Our friend Mike recommended that to me. Any of Zach Gordon's courses, Advanced Gutenberg Development or any of his on Gutenberg. Thanks, Sam. Do we have any more questions for Ryan? It's almost lunchtime. It is. I think everyone's crashing because it's nearly lunchtime. Do you have anything else that you wanted to share today, Ryan? No, that's it. We're good. Massive round of applause for Ryan, everyone. Thank you.