 So, sticking on the coattails of talking about Gutenberg here, my name is Andrew Taylor, and I'm going to talk about tips for block development. So as you're starting to wrap your head around this stuff, what can really help you to learn. I'm A. Taylor M.E. on GitHub and Twitter, so I tweeted out a slide link. There's resources and stuff at the end, the quickest way to follow along, but these are lightning talks, so let's dive in and check it out, right? So, first of all, why learn block development? Just kind of talked about this, it's all about the user experience. And there's things you can do within WordPress, but it's always been extendable. So you can do a lot with WordPress Core, but there are things like custom post types that you can write your own and extend it and do all sorts of things that WordPress Core doesn't do, that's why we have plugins at all. And so when I think about custom blocks, to me it's like creating your plugin for Gutenberg, right? You're creating your custom thing that you're going to add on to whatever is there because they can't fit everything to cover every use case in core, so you're going to have to kind of create your own stuff. It's really about putting that user experience first. So, short codes was great talk leading into this because, let's speak of short code, a ton of those parameters. This is actually showing an example of a data visualization block. And if you look, imagine a short code that you're putting in all these like, oh, I have this many slices of the pie and there are these percentages and you kind of just typing in that text, you don't really get a sense of what that's going to be like until you click publish and go look at the front. This is a completely different experience and you can bring this level of great user experience to your client. So that's really kind of why we're doing this and why you would want to learn it. But, I've been kind of heads down in Gutenberg since about March and it's gone through a lot of changes and stuff. I work at Pantheon and so I know this is going to affect a lot of our agency partners and kind of trying to get ahead of it. And so, if I could go back in time before I started learning all this custom block development and give myself advice in direction, I would. But since I can't do that, I'm here to share it with you all. So, the first thing is starting with PHP. I do write in and I was like, oh, ES6 and React and all this cool stuff. Yeah, I'm going to go take a React course. Like WordPress is still a PHP CMS and there's a lot you can do with PHP. Yes, you will probably eventually write custom blocks, but you don't have to jump all the way there. There's a ton of things you can do to help your projects adopt Gutenberg without jumping straight to custom block development. So, you can add theme support for things. If you've seen a Gutenberg demo, you've probably seen the full width images. That does not come out of the box. Your theme actually has to add theme support and a little bit of CSS to make that work. But adding a few lines into our functions file to opt into that theme support in some CSS is something everyone can do without that giant learning curve. So, start with building this foundation and doing a little bit of Gutenberg adoption within your projects. You can apply block filters. So, if I look at the data visualizations block, maybe I have a finance blog or something and it makes sense on certain post types to have that. Or I have a theme that is for a recipe blog. If I create a block for ingredients, does it make sense to have that and another custom post type that's team members? Probably not, right? Team members don't have ingredients. Like, why even show that block? There's a filter for that. So, you can determine what blocks show up on what post types. And so, rather than have this big list and your users and your clients have to figure out what they should be using and shouldn't be using, you can make that more restrictive and kind of give them some guardrails. Along those same lines, there's post type templates. So, you can actually go in and rather than click create new post type. If we're talking about a recipe, you can already have a title, an image, ingredients, those blocks in there as placeholders. And you can even lock that down. So, maybe I'm doing a post type for team members. And I want an image and a bio and a job title. And that's it. You can actually lock those down so that no matter who goes in to create a team member, there's no wrong way to do it. They have to fill in these fields. They can't add a new image, block in, somebody goes in. Now the CEO's bio looks different than every other page, right? Or whatever. You can block in those couplets. So, determining what you make available to what post types and even using some of these filters, you can do that by user-roller. All kinds of different parameters is kind of put those guardrails in place. And the next thing, once you get past that, and you're gonna start actually doing block development, create a plugin. We're still working with PHP here. We're gonna create a plugin, especially if you're developing a theme. You might say, it'd be cool if I could add some blocks. Do that in a plugin, still have that separation of concerns. Just like if you register a custom post type, that should be in a plugin. So, as somebody switches themes, they don't lose all of those post types. Or you don't lose all of those blocks. The theme should just handle the presentation in the styling. But actually determining what blocks are available should be done in plugins. And I prefer to register my blocks in PHP as well. That's just personal preference, you can register them in JavaScript. But if you're already creating a plugin file and you're doing everything else, just register your block there. And then have the JavaScript files focus on actually handling the editor experience. And that really plays into dynamic blocks. So you can have blocks that will go in and what's output, what's rendered on the page can get saved in the database in static blocks. And that's great for paragraphs and images and things that are pretty simple. But as you start building custom blocks, even adding a little bit of complexity saying that, hey, when this post is in an RSS feed or on mobile, the content should be a little bit different. You can't do that if you have something statically saved to the database. That needs to be done dynamically. So for me, whenever I create a block, I'm creating a new plugin, and queuing my assets, registering the block in PHP, and then I'm doing the render callback in PHP. Even if it's a simple thing I'm doing, that way I have control. And if I go make changes later, then you don't have to go resave the post to get those changes. And so that's kind of a lot of work, right? Create a plugin and then queue strips and register blocks and whatever. Don't start from scratch. A lot of people in the community have been working on this. WPCLI will allow you to scaffold a block plugin. There's Create Goon Block, which is really cool if you want to use more modern ES6 kind of react stuff that will set up Webpack and all that for you. So you don't have to go figure out how to do that. You can just spin up the project and start learning and start hacking. So that's a lot with just PHP. And so start there, get that far, add theme supported templates and decide what blocks are going to be on what post types. And after you get through all that and you're ready to start creating your own blocks, you really do need to understand modern JavaScript. JavaScript has been evolving for a while. ES6 is something you might have heard. It actually stands for ECMAScript. And that version of ECMAScript came out in 2015. And it was the first big change we really had since 2009, 2011. Kind of like there were some tweets in there. But there's been a new version every year since then. So JavaScript has really been evolving, like this big change in 2015. And that has really been more changes every single year. And so with WordPress, we've traditionally done things with JQuery where you're like manipulating the DOM directly in this. So this is a lot of new syntax and just new ways of thinking. So it's like if you're going from functional PHP to object-oriented. It's kind of this big leap and you kind of have to take that leap with JavaScript as well. So you're gonna have to learn to react in JSX. If you're gonna write custom blocks that have more advanced functionality. Like the beginning I showed kind of a Google map was one that I've developed that data visualization, those sorts of things. And it's gonna be really hard to do them with kind of the older JavaScript. You need to learn this more modern JavaScript. And part of that that was difficult for me to wrap my head around with this more modern JavaScript was using existing components. Components is a big deal and react. And it allows you to reuse things so you're not reinventing the wheel, right? We're keeping our code dry, don't repeat yourself. So if you find yourself hard coding a text input, when you're doing this custom block development in this modern JavaScript, you're doing it wrong. If you are actually hard coding a select box, there are components for select boxes and sliders and all that interface you wanna build, the pieces are there. You just need to put them together. The other thing that goes along with that is you need to change the state, not the DOMs. We're not manipulating the DOM directly anymore. State is this concept in react. Goodberg implements it as attributes. So I developed a map block, it had a location. And so I have this attribute for location and you define different states. So if the location is empty, my state is going to be an error message that says location is required. If the location has an invalid address, it will be a different error message. If it's a valid address, then my state is actually going to render the map. So you're just defining these different scenarios, but you don't actually update the DOM. So as the user is typing and location is changing, then React and Goodberg just go in and they say, locations empty. I know that it should be this, that I'm showing. And it actually handles that updating and showing the hiding messages and doing everything else. So you just define the state and kind of how you're supposed to react to it. And it takes care of actually doing all the updating. And it really helped me to review the source code of Goodberg itself. So going in and looking at how the core blocks are built was really, really useful to see, wait, am I doing things properly? Maybe there's a component I wasn't aware of that's not quite documented yet, going in and just seeing what they're doing. And then reading the handbook. So if you go to wordpress.org slash Goodberg slash handbook, there is a ton of knowledge. There's really thorough documentation on a lot of these components. And here's one that, again, you might be tempted to just hard code an SVG. There's an SVG component, but it helps make it accessible, rather than just dropping in your own SVG. So making sure you're using these components, they're well documented. Go read the documentation. There's tutorials on how to get started, creating your first block, and how to register it, and how to enqueue your CSS and JavaScript, and what all of that looks like. And this was one of my favorite parts. Their code samples had traditional JavaScript and the more modern JavaScript. And you could look at that side by side. So as I was learning this more modern JavaScript, going in and seeing what it would be like if I wrote it kind of the old way, and then what it's like, and just seeing those side by side really helped me with understanding the more modern stuff. And then the goals and philosophies. This is really important because I wish I'd read this before I even wrote a line of code, because it talks about really what's the driving force and the principles and the goals behind Gutenberg, but the design philosophies lay out like, hey, if you're doing my location, I originally had it in the advanced sidebar on the right. The user is never going to find it there. So I had to learn that this needs to be in line, like in the block. Well, should I put everything in line in the block and create my own toolbar and go crazy? But reading the design principles, I know what should go there, what should go on the sidebar. And as you're deciding how you're going to structure your block and actually design that user experience, again, you wanted to be seamless with core. So you don't want to have your block be drastically different. I know we've all seen those plugins or themes where you go to every WordPress settings page and they all are consistent. And then you go to that one, and it's completely different. Well, that is what it is. Users can get used to that, but when I go to the certain plugin, it's going to look different. But your block is going to be in the middle of the editor next to every other block. And it's going to stick out like a sore thumb. If you're doing things differently, then the way core is doing it and the way other blocks are doing it. So really understanding the principles behind how they're making decisions and why they decided that this type of input should go here. And if you're doing these things, it should go over here. And really thoroughly understanding that before you actually write code is going to help you make the proper decisions the first time. I had to go back and re-factor a bunch just because I didn't do it right the first time. And if I'd read this, I could have made those decisions properly. And then finally, be prepared for change. So we're in a beta now, but Gutenberg has had to release roughly every two weeks. And that's not going to stop after WordPress by the way it all comes out. There will be another version of WordPress. There will be more iterations on the editor. So if you're developing a custom block, don't just do this, give it to your clients, and then never touch it again. Have a maintenance plan. And know that you should be downloading those betas of Gutenberg. You should be testing your blocks before the new version comes out to make sure that they stay compatible. So this isn't like, I'm going to build something one time. You really have to be prepared to keep up with it as well. So have some resource links. Again, I tweeted out the slides. A-TaylorME on GitHub and Twitter. So please check them out. And you know how fun the links blocks. This one will be for Andrew to just spoke. This was mentioned this morning in the A11Y talk. There was a recent article talking about the failures of Gutenberg, really accessibility in A11. A11Y, and I was wondering if you could, if you know about that or if you can speak to it. You know, I'm not on the Gutenberg team or anything, obviously. I'm just developing blocks for myself and projects that I'm working on. And I haven't developed blocks for a project that has heavy accessibility requirements yet. And if such a project came up, that would be a challenge. I'd have to tackle it that fun, but I really haven't done that deep into it. If someone doesn't know any job strength that I have up close to a page beta developer, where would you start? Because you have all this old information, I have all this new information, how do you do it? I don't know. It's hard to point at Andrew's first few slides where he's talking about things you can do to work with Google where you're not actually building a block, where you're just making your sites more accessible to Gutenberg. And then also, as mentioned, you can actually register your blocks and do things with them in PHP and then slowly work up to the JavaScript part. Yeah, and with the JavaScript part, there are fundamentals you'll need to learn that ES6 wasn't that big of a chain. So figuring out how objects and arrays work in the more modern JavaScript, there's some nice array functions like map is a new one that wasn't there before. And so, but just learning the basics of arrays, you'll have to wrap your head around first and then decide if you want all of that syntactic sugar and some of the new stuff on top of it in the transpilers. Westpask has a course that's like JavaScript, like 30 for 30 or something. It's like each day you build a new app with just vanilla JavaScript. So kind of maybe build that foundation and then go look at, Mozilla has a great listing of everything that's new in ES6 and kind of shows you all the functions and walks through it. So maybe start with vanilla and then go look at the new stuff and go, oh, I wish I had that, right? So a question for Andrew, you talked about maintainability. And I was wondering if you noticed a difference between your previous workflow and your current with building blocks in terms of increased or decreased or same across the board, time investment? So time investment, like initially when building blocks, it's when you're learning something new and there's that steep learning curve, your time investment is more, right? And the more experience you have, you can kind of turn that down. I think it also depends on the complexity of the blocks and the requirements, right? So if you're building a simple block, then it's not gonna be as much to build initially and maintain, but if you have something more complex and maybe like users at different roles should have different experiences within the editor and somebody can add stuff in, but then another user will have to like, if it starts getting really complex, the more you put into it, the more time you're gonna have to spend on maintenance. And so that's just kind of the projects in general that are going to help you build blocks or anything different.