 Okay good afternoon everyone. We have Joshua Giovaia here. Joshua Giovaia is a senior front-end developer at Code 42 who started his career as an action script and flash designer. He has an extensive background in design that has proven invaluable when contributing to the design process and communicating with creative teams. He stays extremely active in the WordPress community, regularly attending and speaking at work camps and lead-ups. He hopes to give back to a community that has shared so much knowledge with him. Give a warm welcome to Joshua Giovaia. Thank you. Thank you to the organizers. This has been an awesome event so far. Thank you for coming to my talk and sticking around for the last talk on the last day. Like I said, my name is Joshua Giovaia. I'm a senior front-end developer at Code 42. We developed a software called Crash Blend. Helps companies back up and restore their desktops and laptops and devices. I've been doing this for about 12 years now. Started with flash and action script development which just died on the line one day. It's always fun to have to reinvent your career. So I'm not afraid to change so Gutenberg doesn't really scare me and I was happy to embrace it on a project earlier this year. This is a legacy for a developer, a modular approach to WordPress development. It's been really great implementing this as a workflow. At Code 42 it's made my life immensely easier and made our communication with our design and content partners so much easier. What we'll be talking about today is what is modularity? Why would you want to change your approach to modular? Modular approach will walk through from wireframe to website kind of the process we had at Code 42. Moving away from page templates and getting into reusable modules. There'll be a GitHub repo where you can get started today with that approach. And then we'll talk about Gutenberg and atomic design how you get started with modularity with Gutenberg today as well. Legos. We all love these things. They're so great. They come with a set of instructions and you can go that way or you can build your own path and build your own thing. This is my hometown of Minneapolis, Minnesota, the Mall of America. I think they probably had to follow instructions to get this one done. I'm not sure. Pretty complex stuff but I would say as developers we do pretty complex things as well. So breaking down into modules or blocks and making them more consumable is an awesome thing. Right now I just need two volunteers from the audience. Come on I know it's the last day. You don't want to play with Legos. You can't go talk about Legos and you don't want to play with Legos. You got one. You got one. Okay. Thank you for volunteering. So I designed this awesome Lego website and I'm gonna need you two to recreate it. One of you is gonna have the modular approach and one of you is gonna have the current approach. You can take modularity and you... Oh, sorry. There you go. There's probably a couple of missing pieces. I've done that a couple times. So this is our kind of workflow, right? We have all these code snippets and past projects that we use and we get our project and we're like, oh I know I've done that carousel before. I'm gonna go over here, copy paste this code or I don't remember where I did that before. I remember where I saw that before. We used it all together based on these little snippets that we've had throughout time. And this is a modular approach where we look at this as a reusable pattern that we've seen before and decide at the outset of our project that we're gonna make it reusable so we can transfer it from project to project and also reuse it in our current project. So this is a fierce race. He actually got a pretty good head start. Oh, we got a winner. Thank you so much. So I think there's three things to understand when you want to go modular or you want to get into this workflow. The first is having a pattern language or a shared way to talk about these modules that makes sense to everybody in the project. There's a book about this, written by Christopher Alexander, where he came up with 253 patterns and talents in instruction. We all, or some of us working offices, these are a couple of those communal eating, small work groups. Reception welcomes you. A place to wait. So he came up with this language where everyone understands this is what we're talking about when we say these things. And that's the first part of going modular. Super important. The second part is an atomic design strategy. This is created by a guy named Brad Frost and it has five distinct stages to make your code more deliberate and hierarchical. Those stages are atoms, molecules, organisms, templates, which we currently use in our workflow, and pages, which we also currently use in our workflow. This is the Instagram interface. And so, I like to think of atoms as typography, colors theory, iconography. And then two or more atoms make a molecule and molecules make up organisms. Modules and blocks are kind of interchangeable known in Clayture when we're talking about doing modularity and atomic design within WordPress. And then you see those organisms make a template. Those templates make a page. So let's take a look at another familiar interface. We've got our atoms here, typography, colors theory. They're making our molecules. Then our organisms or modules or blocks are being repeated down the page. And we see that, you know, this is reusable all over the place. There's another view where once again it's reusable. And the third part is modular design written by a guy named Nathan Curtis. And it's comprised of two patterns, content patterns and display patterns. A content pattern is a reoccurring design problem such that it can be used many times and never used the same way twice. And a display pattern describes a specific rendering applied to multiple content patterns. So this is Yelp's style guide or pattern library and this is where all three of those things kind of come together. You see we have very deliberate namings. User passport, full passport, medium passport, standard passport. So if someone were to say let's up the font size on the standard passport everybody in the project would know what they're talking about. And we get a look at how the content is going to be rendered. As you can see it's the same content pattern, right? We have an image to one side, information about that image to another side. And it's being rendered different ways each time. We can see that here. Same content pattern, render in a different display pattern. And again. So what's really cool about what Nathan Kurt is kind of describes and talks about is like we saw earlier from the demo, this is kind of our current ideal workflow in where we have all these snippets and pieces and we want to build this really deliberate thing. We can do that and it works. But if we categorize and look at these things and call them out on the onset of the project we can build multiple things with those same pieces. One of the advantages, dry coat. More collaborative and iterative process. And power admins and content editor. We don't want to write the same carousel code over and over again or the same hero manner over and over again. But the only thing that changes is they want body text or they want two buttons. This approach is broken. Waterfall is broken. We get in a room and we get in a project. Project kickoff. Everyone's excited. There's stakeholders, there's designers, there's content editors there. And then we go away for two, sometimes three months. We get the content back. We're like cool, now we can start designing. And design goes away for two, maybe three months. We get the design back. We're like cool, now we can start development. Development goes away for whatever time it's left in the project scope, which is normally two weeks. And then we come back and we present this project to the client who hasn't been in the room for nine months. And they're like what is, I don't remember this. What is this? And no one's happy. So when I say more collaborative and iterative, what I mean is we're looking at these things at a modular level. We're talking about these things in verbiage and words that we can all understand. And we're iterating on them as we're creating each module or each block. We're saying, hey content, does this look right for the data schema? Yeah, that looks right. We're saying, hey designs, does this look right for the display layer? Yeah, it looks good. Hey developers, everything okay? Is there anything else that we need to change before we call this one block and module good? You get true ads out of this. I mean you could have a two week sprint and where you do three modules or three modules. And empower admins and content editors. At code 42, our content editors have created over 500 other landing pages and web pages without any dev intervention. We started with 13 modules. We now have 22. And if you can imagine they can reconfigure them in any order so they can make some really unique layouts without having to come back to their development team and say, hey we need this or hey we need that. That way we get to work on new features all the time. So how do we get here? Well the first thing we need to do is identify the patterns. Is it the content pattern or design pattern? Or is it the pattern horizon? A lot of times I'll get a mock-up and even if they don't follow atomic design or haven't broken it down into modules, I'll take the entire design layout and screenshot everything I think is a similar content pattern and then make sure that I have a display pattern that accounts for all the different use cases. So we started our project. All we had was wireframes. The content team had been working on the project. The design team came with wireframes and we were able to start development right then and there. So we were able to start planning out our content patterns as soon as we got the wireframes and start to talk about hey are you really going to need an extra button? How many headlines are we going to have? Super powerful to get a leg up on development right away. It's amazing. So how do we categorize those patterns? Content pattern you can use an ACF field. How many of you guys are familiar with ACF? Cool. How many of you guys use flexible content with ACF? Better. So you can just start categorizing the content patterns right away using ACF. Design patterns we have an individual SAS file for each one of our modules or organ albums. So this is what our style guide looks like and this is how we got to our templates and our modules. We've got atoms, like I said, no, typography, color theory. We've got molecules made of the two more atoms. We've got organisms and that's reusable everywhere. See it in our template, reconfigurable, works for it. How do we organize our SAS? Well in overarching SAS files we put our color typography molecules, we put that in our theme or layout SAS files. And then organisms or modules they get their own SAS file. So this is what it looks like on the back end after we've created the modules and we can reconfigure them using ACF in flexible content. This is the actual code for one of the modules. This is the hero module here and as you see it's pretty basic stuff that you can use ACS before. This is the individual SAS file and then we use ACF JSON to make sure that all of our modules and our constant patterns are synced with all of our developers. I don't know if you guys are familiar with that or not but you just create a folder called ACF JSON, plot it right near theme directory and it automatically hashes every time you change one of these modules or field values. So this is what it looks like on the back end. So we have all our configurable content options here. I like to add a theme option so they can decide what of the color theories they want to apply here. They can give them the ability to center the content anywhere they want. And then of course if you've ever used this before you know it just kind of slides, pops up, the trigger rule, the whole deal, add an intersection here. It's awesome. So how do we achieve this in our code? We use something called git template part. I mean if you're familiar with that. Cool. So this is a module page template and basically what it's doing is just grabbing all our modules that we predefined in ACF. It's calling another function that's going to loop through those and if we don't have any defined we're going to call another function that's actually going to bring back the content of that page or post instead. And this is what the module loop does. It finds out what the field name is and then it uses our directory and naming event structure to string replace and make sure that it's grabbing the correct line. And then once we grab that module we locate template part and it already has a name that was just passed to it and created in our previous function. We have to set the flag to false so it doesn't only load once because that way if we have multiple modules on the page it wouldn't render the second module in that series. This is a link to a repo and where you can download a theme that's a sage theme that has all this code in it already. We kind of already saw all the flexible content stuff. There might be one more thing I want to show you here. This is the file structure that we use for that and we just put it under templates, modules and it goes out and gets the correct module. We just loop through each one so we don't have to worry about calling each one each time. So Gutenberg and Atomic Design this is the coolest thing to happen I feel like for someone who takes this approach because it is super easy to get started with and it's amazing. We did a project earlier this year using Gutenberg and it couldn't be easier. So this is how the same structure that we were talking about just kind of lays out Gutenberg. Gutenberg has this awesome sidebar feature where you can have your user define different typography, color theory and that's where we like to keep our atom level styles. Our molecules are comprised of the components that Gutenberg has predefined in it or if you want to roll your own component you can do the same. And a block is basically equal to organism, those organisms create templates, those templates create pages. There is a reput called Create Gutenberg block and it's super easy to get started with. Just the MPM package, download and install it. It's pretty awesome. So this is it. I actually ran this about 10 minutes before I walked in here. So I just ran that function on MPM and it just went ahead and created my Gutenberg block plugin. It does a really good job of organizing your file structure and calling out the things you need. So let's take a look at that. We have our block here. First thing we need to do is register our block. Let's take a look at that. So right here we're just registering our block, telling it the name of the file or to grab it from what CSS use on the editor side. Right here we're creating our block. We've registered our block type, we're passing in these variables, the title, our icon, what category it goes into in the Gutenberg interface, and then keywords for searching for the user. This is our edit function where we define our props. And this is our save function where we tell the block what to render out based on the initial props we allow them to edit. Editor CSS defines CSS you want the user to see in the editor and then style CSS defines what you want the user to see on the front side. And it's simple. We just import block. One thing about this plugin is they use Webpack. So you might need to know a little bit about that, but pretty unlikely. And then here's our block for example. There's about 10 minutes earlier. Drag and drop. You get all the functionality out of the box. Pretty sweet. This is that sidebar. The block right here you see we got our seal. Add another one if we want. Perfect. Here's some resources. If you want to get started with atomic design, modular development, modular strategies, there's some Gutenberg resources. That's it. Any questions? I assume that the moment Gutenberg blocks can't be used in other areas of the site, like sidebars or header and footer, just in the, not really just for the content, but the blocks that you create using Gutenberg blocks can't be used in sidebars. Not currently. I mean there might be a plugin or a repo or something like that, but not out of the box. What would be your outcome? What's your desired outcome for doing something like that? Oh, I don't know. I mean, I can imagine where I would if we still use sidebars, we still use headers and footers, and if we're unifying the process of creating blocks and starting to use Gutenberg, it would be nice to centralize that rather than have two different systems of creating blocks. Well, what would be nice if they did that and gave it a local namespace so you could re-use, they could use the re-use function of Gutenberg everywhere. When you, we're kind of talking about making custom blocks, did you have any experience yet with ACF beta that helps make blocks? No, I haven't had any experience with it. I've been following and reading up on it, but if they do end up doing that, it would be a really smooth transition for anyone who uses the ACF way to create modules and want to integrate that into Gutenberg, but I haven't tested it or tried it, but I'm hoping that the project turns out well. Yeah, I tried some because we already do, for our company, we already do a modular approach very similar to what you're doing when we're using flexible content, and migrating from flexible content to blocks with the advanced custom fields, Gutenberg block stuff is pretty seamless and you didn't have to make a great react, which I don't know if the react itself is really nice for me. Okay, more questions. Just put a pretty one first, okay. Okay, well, thank you.