 All right. Can everyone hear me? Cool. We're going to go ahead and get started then. Thank you for coming. And welcome to DrupalCon New Orleans. And welcome to this session. Understanding and using render arrays in Drupal 8. I'm Gus Childs. And I live in Golden, Colorado. But I'm originally from St. Louis, Missouri. So go blues. But Gus Childs is my handle basically everywhere. So feel free to track me down on Twitter or drupal.org if you end up with a question. And don't get to ask. And I work for Chromatic. You can find Chromatic on the webs at chromatichq.com or on Twitter at chromatichq as well. So Chromatic is a completely distributed company that works primarily with Drupal. We've got team members all over the US and a couple in Europe. And we work on a lot of really interesting projects with some pretty big name clients. We've actually, I think, got a couple positions open. So if you might be interested in joining a unique team, find someone wearing one of these shirts. I'll give you a hint. There's a lot of them right here. And we've actually also got a number of these shirts that we'd like to give away. So track one of us down if you want to figure out how to get your hands on one of those as well. But anyway, as you might have guessed, I'm primarily a front-end developer. But I say primarily because it's a front-end developer that works with Drupal. It's pretty easy to stray into territory that no longer feels like front-end development. It's pretty easy to find yourself away from the world of HTML and CSS and JavaScript and find yourself in a fight to the death with PHP. But that's often life as a front-end Drupal developer or a themeer, you could say. But that's what this session is about. There will be quite a bit of PHP. But hopefully, you are going to leave this session more comfortable with what's going on back there, what's happening before the template. So let's talk about render arrays. But why do I care so much about render arrays? Well, I've been working with the same client for the last year. And they're a very large media company that manages a lot of Drupal sites. They've got a few multi-site repositories. And they've been doing one rebuild or redesign after another. And their requirements for each site often look a lot like this. We want to build this feature just like we built it on the last site. But it needs to be slightly different on this site. So as a developer, you think, OK, how are we going to accomplish this? Well, we could copy and paste all of that code that we wrote for the last site, paste it into the new site, change the little bits that need to be different for this site. And that would work. But this should definitely invoke visions of this popular acronym, dry or DRY. Don't repeat yourself. We don't want to copy and paste a ton of code because that's twice the amount of code we're going to have to maintain, twice the bugs we're going to have to fix. And this organization has a ton of sites, not just two. So that is not scalable. But we work with Drupal. So we know the better answer is abstraction. I mean, after all, that's how the Drupal ecosystem of contributed modules is able to work. Everything is done in a very general way that can be configured for site-specific needs. And so any custom code that we're writing for our clients can and should be built with the same goal. So while building themes for this client, I quickly began to realize that render arrays are definitely abstract. They're both, they're abstract both in the sense that they're very difficult to understand at times, but they're abstract in the sense that they allow us to write code that all the sites can use in a way that each site can still accomplish its unique goals at the same time, which is much better than copying and pasting a lot of code. Because again, we're trying to not repeat ourselves. Another reason I like to speak about render arrays is because once I really started understanding them while working with this client, I realized just how big of a role they play rendering the entire page, the page itself and everything on it. I also realized I definitely wasn't alone in not understanding them. I don't know that really that many people do. So everyone jokes about Drupal's arrays of doom, but it seems like few can kind of really dive into them, get what they need and come out alive. So that's why we're talking about render arrays today and hopefully we're going to change that. But you might have one more question. Arrays in Drupal 8, what? I thought Drupal 8 was object-oriented. Well, it is most of it, but a lot of the render API is still array-based and a lot of the theme system is still procedural. It seems that this is because most of the attention given to the theme system between Drupal 7 and Drupal 8 went to something else you've probably heard a little bit about, which is Twig, the new templating engine. And that's for a good reason. It's a huge improvement. There's plenty to be excited about. But from what I can tell in the issue queues, Twig took so much time and energy to implement that there wasn't enough left to drastically alter the rest of the theme system before Drupal 8's code and API freeze. So render arrays remain in Drupal 8. I think it's safe to say also that those that are very familiar with them sometimes love to hate them. And there's plenty of great ideas floating around about where to go next. I'll talk a little bit more about that at the end. But the fact is render arrays currently play a bigger role in Drupal 8 than they did in Drupal 7. So we're gonna accept and learn their ways here today. And we're gonna be learning their ways with a lot of small code samples. And I'm gonna be doing my best to mark which code samples are Drupal 7 versus Drupal 8. But as I mentioned, they're gonna look pretty similar in most situations. So this means it's never too late to start using this knowledge in Drupal 7 too. So let's get started. I'm gonna speak specifically about what a render array looks like, how render arrays work, why they're useful, a little bit about the render API as a whole, and the future of render arrays. So what do render arrays look like? So as the session description mentions, there are two ways to turn data into markup in Drupal 7, the theme function and render arrays. When we're using either one at a very basic level, they actually look very similar. In all of the core and contrib and custom code I've seen written for Drupal 7, I see theme being called a lot more often than I see render arrays being used. So I'm gonna assume we're a little more familiar with that. Let's start there with the theme function. So here's what using the theme function looks like in Drupal 7. Here we're rendering an image with a given path and an alt attribute variable. So the first argument is the theme hook to use. And I'm gonna get more into what that means exactly later, but that's how we tell Drupal that we're rendering an image. The second argument is an array of variables. And in this case, we're providing the path to our logo and the text we want to print in the alt tag. I'll also discuss later what determines what variables we can use here when we're calling this function. But for images, these are two of the few that we can use. So this is what the equivalent render array looks like. As I said before, it actually looks very similar. Just like with the theme function, we're passing which theme hook we want to use. But instead of passing it as an argument, we're passing it as an item in the same array that is keyed by hash theme. And I'll explain more about how that works later also. But right now we're just getting familiar with what they look like. And we're also passing the path and alt variables that we'd like Drupal to use when we're rendering our image. The same data that we passed to the theme function. So there you have it. That's what a render array looks like. But what's the difference? So let's go back to using the theme function. So this is actually calling a function and functions return something. So what the theme function returns is rendered markup. So after this code is executed and the result is assigned to that logo variable, if we go ahead and print that string say in a template, we'll get the image tag with the source and alt attributes that we passed along. But our render array is just an array. It's not markup yet. And we haven't called any functions to do anything with it. So how do we get from our array to our markup? Well, if we try and print that variable in the same way in our template, it's gonna print the word array. I've had this happen to me a million times while working with Drupal 7. And if you have two, this is likely the reason you have to act on that array before you print it. So we do that instead of just printing our array variable, we run it through the render function. And again, this is Drupal 7 still. And so we normally try and avoid calling functions in Drupal 7 templates, but the render function's kind of an exception and it's totally expected and recommended to call it from there. But what it's gonna do is it's going to turn that array into the right markup, which is our image tag. The same markup that we got from the theme function. In a twig template in Drupal 8, rendering our render array is as easy as printing any other variable. This is gonna recognize that the variable is a render array and it's gonna turn it into markup. Basically a little, some of the many pieces of magic in twig. And I'm not gonna go too deep into twig. There's plenty of great sessions about it. I think the last one in this room was about twig. But just know that you don't have to worry about the render function in Drupal 8 or the equivalent, at least from within a template. So regardless of which version of Drupal we're working with, the fact that our variable is still an array until this point is why render arrays are superior to using the theme function, which immediately creates markup. It makes very little difference with this simple example so far, but it's gonna make a big difference when things get a lot more complex. The other thing to know about what render arrays look like is that you're often going to see them nested inside of other arrays. So for example, Drupal 8, sorry, Drupal builds the page with deeply nested arrays. It looks something like this. This is very simplified, but you've got your regions essentially here on the first level, your header, your content, sidebar, and footer. And inside of each of those regions are gonna be even more arrays containing the content that should be printed when the page is rendered. So printing a portion of that array, such as the content region, is gonna look like this in Drupal 7's page template, and it looks like this in the page template of Drupal 8's stable theme. So what Drupal is gonna do when it's told to render a nested array like this is it's gonna dig into every item. It's just gonna keep going down, drilling inside of it. It's gonna find the arrays with hashed keys, and it's gonna see those as render arrays, and it's gonna attempt to render them as such. And any array key without the hash, it's gonna continue digging into to try and find more things to render. So that's why render array keys start with a hash to differentiate them from arrays that are used to organize render arrays, or data, or anything else. And Drupal doesn't actually care what the non-hashed array keys are. They're more for organization, or in this case, just to match the names of your regions and things like that. But when it gets to a render array, the actual names of those properties become a lot more important, and they need to be specific. So that's what they look like. How do render arrays work? How does Drupal 7's render function, or Drupal 8's twig engine, know how to take our render array and turn it into markup? So to understand that, we're gonna take a bit of a deep dive into the theme system. The session description doesn't really mention that we would do this, but it's kind of hard to understand render arrays and their benefits without understanding the basics of the theme system. So this could definitely easily be a session of its own, but we're gonna aim for the quickest version that we can. So it's all gonna start in the theme system with hook theme. Hook theme is where most everything that gets rendered is initially defined. And this is a very simplified and kind of changed around version of it, but this is what hook theme kind of looks like within Core's system module. And that's where a lot of the common elements that we're probably used to are initially defined. So what we have here are HTML and page. It's probably likely that a number of us in this room have worked with the HTML and page templates before, and that's where they're initially defined. So that was Drupal 7, this is Drupal 8, and once again they look almost identical, except you don't have to explicitly name what the name of the template is. I'll explain a bit more about that in a little bit, and also what a render element is a little bit later, but for now just understand that anything rendered through the theme function in Drupal 7 or through a render array in Drupal 7 or 8 is gonna be initially defined with hook theme. Now in that same implementation of hook theme within the system module, our image theme hook used in our previous examples is also defined, but this looks a little bit different. It looks a little different than the HTML and page examples because here we're defining a list of variables that can be used with this theme hook and the default values they're gonna use if we don't give them an explicit value ourselves. Two of those variables are the path and the alt variables, which are what we used in our previous examples. So we're starting to connect the dots here. When we're rendering our render array, the theme property is the theme hook to use, which is defined in hook theme somewhere. And the other properties are the variables to use when rendering that theme hook. And in this example, in addition to path and alt, we could have used any of the other variables, the dimensions variables, the width and the height or pass the title attribute or any other attribute we wanted through the attributes array. And if they're given a value by a render array, then when rendering the markup, Drupal is going to use those. But what we've been looking at here is Drupal 7, the definition of the image theme hook in Drupal 7. So let's take a look at what that looks like in Drupal 8. Very similar. The only differences here between 7 and 8's images, image theme hook, are instead of passing a path, we're now gonna pass a URI and there are a few new variables as well. The sizes and source set variables are gonna help us build responsive images and we can also pass the name of an image style. So if this was our render array in Drupal 7 and we needed to port it to Drupal 8, it might look something like this. All we had to do is update our path to a URI and aside from that, it's gonna look just the same. But let's say we wanted to take advantage of those new variables and we want to render a responsive image. We don't necessarily need to go too far into how responsive images work, but that might look something like this. Our example got quite a bit more complicated pretty quickly, but as you can see, we're passing along values for the sizes and source set attribute. We're saying that our image is gonna be 100% of the viewport width and we are saying we are telling the browser to pick between one of two images, either our thumbnail, which is 250 pixels wide or the large image style derivative, which is 750 wide. So when we render this render array, Drupal is gonna take that additional information and it's gonna use it to construct our markup once again. So if we ran this new render array, our markup is going to end up looking something like this. So the source and the alt attributes look the same, but you can see that the data we passed along for the sizes and the source set attributes have been taken into account and added to our image tag as well. But even though we know what initially defines our image theme hook and the variables that we can use with it, how do we get from this crazy array to our complex image tag markup? There's obviously gotta be steps in between there. What's Drupal doing? So to jump back to our hook theme example in Drupal 7, a theme hook is going to be rendered in one of two ways. The first way is a template and like I said before, we've probably worked with the HTML and page templates or seen them in our themes. But our image example only defined variables and never defined a template name and you've probably never worked with a template named image.tpl.php. So if it's not rendered through a template, how is it rendered? With, and again, this is all Drupal 7 for right now, with something called a theme function. Theme functions are named theme underscore and then the name of our theme hook. And as you can see here, what the theme image function is doing is it's taking the path that we passed along and it's assigning that to our source attribute and then it's gonna take any other variables that we've passed along and assign those to attributes as well. And then there at the bottom, it's gonna flatten them into a string and print them within our image tag. That's a theme function, but you don't need to worry about those anymore because all theme functions were removed from Drupal 8 last year and they were all replaced with templates. And you can hug your local theme system maintainer for killing all theme functions because they got really ugly really fast. This is theme item list, which in Drupal 7 is used to render a simple item list, an unordered list, an ordered list. Now, if I wanted to make any changes to the markup that this outputs, I'm gonna have to copy and paste the entire thing to override it and make changes from there. But we don't wanna be repeating ourselves, we don't wanna be constructing markup in PHP like that. So theme functions are dead again. That's why you no longer have to name the template from within hook theme in Drupal 8 because core is going to assume that you're working with the template. So instead of theme image living on in Drupal 8, we have our image.html.twig file instead. But that only prints the attributes object inside of the image tag. What happened to all the logic at the top that took our variables and kind of prepared them into attributes that got printed in that image tag? What's gonna take the value of our source set and sizes and URI and ALT and turn those into strings that the template can print? The answer to that is preprocess functions. And this is core's preprocess function for the image theme hook. So preprocess functions are named with a prefix of either the word template, the name of module or the name of the theme, and they're gonna get called in that order template underscore whatever any that are defined in modules and any defined in themes. And then you have the word preprocess and then the name of the theme hook. So for this specific preprocess function, you can see that core is taking the value of our URI variable and assigning it to the source attribute. Then there's a lot of code that I commented out so I could fit the rest on this slide. But it takes all of the data that you pass in the source set array and turns it into flattened strings for that attribute. And then finally it takes the rest of whatever other variables you pass along, which are a lot more simple and assigns them to the attributes array as well. And that's what gets printed in the template. While I'm talking about preprocess functions, you might have also heard of process functions in Drupal 7. Those no longer live on in Drupal 8 because process functions were typically used to do the flattening of an array to a string like calling the Drupal attributes function. Twig is magical, you don't need to do that. So process functions are dead, they do not exist in Drupal 8. Just thought I should mention that. And actually a lot of folks are moving their markup logic from preprocess functions back into the template. And there's actually even a core issue to do this with the image template and with the preprocess function that we just looked at for the image theme hook. And this is the node template within the classy theme within core. So with this approach, some folks would even argue that there's no need for preprocess functions anymore, but that's a different discussion for a different day. But that's a big portion of the theme system in a nutshell. Hopefully I didn't lose you there to recap a tiny bit on that. Our initial definition of a theme hook is gonna live within hook theme and that's gonna tell us what variables we can use from within our render array. And when we render that render array from within a template, its variables are gonna be ran through any preprocess functions that may exist. And again, modules and themes can define these two and we'll get into that later. But it's gonna run any preprocess functions to prepare variables that are going to be printed in the template. And that's how we get the resulting markup that we wanted. Hooray. So hopefully now you have a better understanding of the theme system and how render arrays work, which is great and all, but why are render arrays useful? Kind of the whole point of this session. Why should I go through all of that trouble just to render an image tag? Why can't I kind of hard code most of the markup myself and put maybe variables in the dynamic bits? So why should I use render arrays and why is the theme function? Why does that no longer exist in Drupal 8? So I've used the word theme about a thousand times so far and I apologize, but that's Drupal. But in the theme system rundown I mentioned that there are no more theme functions like theme image and core anymore, done talking about that. I also discussed hook theme as what initially defines theme hooks to use with our render arrays, done talking about that too. So let's talk about the theme function. After all, again, the session description mentions it quite a bit. So here is our example once again from the beginning of the session. So this is how the theme function is used and it was called a lot in Drupal 7. I think over 200 times in core and it was used all throughout contrib modules as well. A lot of the custom code I've worked with, a lot of the custom code I used to write littered with the theme function. And as we can see on the documentation page on Drupal.org for it, it's been around since Drupal 4.6. So it's definitely not new but it's not listed for Drupal 8, which normally what that means is you need to go find the object-oriented equivalent, maybe dig through the comments on that page or do some Googling. But there's no direct object-oriented equivalent for this either. It's just not there. And in fact, the same page has this comment a little further down in the documentation. Avoid calling this function directly. It's preferable to replace direct calls to the theme function with calls to Drupal render, which is the render function I've been showing you as a wrapper for Drupal render, so almost the same thing, with calls to Drupal render by passing a render array with the theme key to Drupal render, which in turn calls theme. So it's not gonna turn it into markup until we call render. So to understand why we're not fans of the theme function and why it's no longer, let's use this as our example. So this is a portion of the page template within Drupal 7 that prints the site logo on the page. This is in the system module of Drupal 7 to print the site logo on the page. Specifically, here is our line that prints the actual image tag, which this isn't using the theme function or a render array. So this is kind of the question I asked a minute or two ago. Why should I bother with a confusing render array for an image tag when I could just create simpler variables for the dynamic bits, like in this situation, the source attribute, when I could just create variables for those? So let's think about that logo variable though. So, and this is drastically simplified, but the logo variable is built within core's template preprocess page function. And when I say simplified, I mean I basically remove the rest of the function so we could focus on this. But this is how that logo variable's created. So as you can see here, it's using the logo theme setting to figure out what the source attribute's gonna be. So if you go to your appearance page on your theme and there's a place to put in the path of your logo, that's how this, that gets used. But what if it's not that simple? What if we need a different logo on the homepage? So as I mentioned before, any modules or themes can implement the same preprocess functions. So what if we implemented this preprocess function from within our theme? And we use Drupal as front page to figure out if it's a homepage. And if it is, we change the path of our logo variable. And so now, if we're on the homepage, our logo variable is gonna print our homepage's logo in the page template. So that works still. But what if it's not that simple? What if we wanted to do something as simple as add a class to this image tag? Because maybe with our CSS or JavaScript, we don't wanna target the image directly, we wanna target something with a class. So we wanna add a class. But that's gonna become pretty silly pretty fast. Because we're gonna have to override the entire page template just to alter this image tag's markups. So if you're familiar with templates, you'd know you'd have to copy and paste this into your theme, the entire thing, just to add, say, a class to your logo. That's a lot of copying and pasted code, not very dry. So let's pretend that Drupal 7 Core's page template was a little more sane. Let's pretend that it prints a logo variable instead that prints the entire image tag. And that logo, and the construction of that tag has been moved into a pre-process function. So here we'd be doing that with the theme function. And something like this is going to print the exact same markup. We're gonna get the path we want from our theme setting and we're gonna get the same alt attribute value. So again, this is the theme function, not a render array. But so now we want to add a class from within our pre-process function to what this has started for us with the logo variable. So we create our pre-process function within our theme and we use develop and we go to DPM, the logo variable, to see what it is at this time to see how we're gonna add our class. But the theme function is gonna return something and it's gonna return rendered markup. So how are we supposed to add a class to this markup that's already rendered? Well, this will work. Okay, so judging by the reaction, I don't need to tell you that this is not ideal. And in situations with more complex markup, this is obviously not gonna be an option. We don't wanna start writing regular expressions to do insane things. So instead, instead of using the theme function to initially create that logo variable, and again, this is theoretical core doing its work, instead we're going to construct that logo variable using a render array. And this is gonna produce the same markup that was hard-coded into the template and this is gonna produce the same markup that was returned by the previous example of the theme function. Once again, we go to DPM that variable from within our themes pre-process function to see what we're working with, and it's still an array. So we could totally work with this. We can add our class to the attributes property in our render array. And now this is what the current state of the logo variable looks like. This is what our render array looks like. It has the class that we just added. And it's gonna remain an array until the template calls the render function on that variable and we'll get the markup that we're looking for without altering the page template at all, without repeating any code, just one line from a pre-process function. So this accomplishes our original goal and helps us solve our original problem. Whether it's a contrib module that we're maintaining and it's being used in ways we can't even imagine or a theme, a base theme perhaps, or a custom module or theme that we're building that's used by multiple sites, the render arrays that we've built are gonna make it really easy for other modules or child themes or future us on another project to use pre-process functions to make small alterations needed to accomplish the specific requirements of that site without changing the code that all of our other sites are sharing. No copying and paste just override something and we're not repeating ourselves. I'm repeating myself, but not in code. Or if someone wanted to alter those variables from within the template itself before they're printed, they can totally do that too, doesn't have to be a pre-process function. Either way, we've successfully abstracted everything and we've made the lives of anyone trying to extend or alter our code easier. So that is why render arrays exist and that's why we should use them. So now that we've seen them, we've seen some examples, we've been all around the theme system, let's take another step back and let's look at a few other important pieces of the render API that we're probably going to interact with when we're working with render arrays. But more definitions, what do I even mean by the render API? We've already learned about the theme system. What's the difference between that and the render API? Which is a question I asked myself a bunch, that's why I felt it was important enough to put in here. So I'm gonna do my best to sort that out. So the theme system includes the hooks we've talked about earlier. We've got hook theme, pre-process hooks. We didn't talk about theme suggestion hooks, those are kind of new in Drupal 8 and very useful. And then we've got the twig templating engine. Then the render API is an API used by the theme system when you're taking data and turning it into markup. So there's more to it than this, but these are the bigger pieces I'm gonna touch on really quick. We've got render arrays, render elements, caching, attachments, and placeholders. So to dig a little deeper into these, how you're often going to interact with the render API is through the reserved properties that you can use within your render arrays. Again, these aren't all of them, but these are some of the more commonly used ones. So up until now, our examples have used the theme property and properties named after our variables to build our render arrays. And just to kind of put a lid on render arrays and understand their role in the overall render API, we've got this quote, render arrays are the core structure, sorry, the core structure of the render API is the render array, which is a hierarchical associative array containing data to be rendered in properties describing how the data should be rendered, but it's the core structure of the render API. So we get that now, we've talked enough about render arrays. So we're gonna move on to render elements, which for a long time were very confusing to me. Still are sometimes, but the most helpful way of thinking about render elements that I've found reads, modules have the capability of defining elements, which are essentially pre-packaged default render arrays. So I've highlighted the important part, pre-packaged default render arrays. So let's take a look at an example of the definition of a render element in Drupal 8. So here's the checkbox render element in Drupal 8. And there's a few things to notice here. First off, it's actually object oriented. This is because render elements have been moved to the plugin system in Drupal 8. In Drupal 7, you would use hook element info. Most info hooks were moved to the plugin system. So here is the checkbox render element, build the plugin system. The other thing that we'll see is that the render elements get info, and this isn't the whole class, but the other thing we'll see is that the render elements get info method returns something that looks a lot like the render arrays we've been looking at. So this is where the previous definition comes into play. A render element is a pre-packaged default render array. So our render element defines all of these defaults so that we don't have to. Instead, to make our checkbox, all we have to do is this. And this looks a lot like our render arrays. Instead of our theme property, we have type, and we're using that to specify that we want a checkbox, and then we can pass along other variables that we want to use, such as the title for the label of that checkbox. The rest of the information for our checkbox is gonna come from the defaults defined in the render elements class, which can, of course, be altered or extended if you need. And you'll even see that in this render array we've got the theme property specifying the theme hook that this render element is gonna be rendered with. So when our checkbox's markup is being built, that's the theme hook that Drupal's gonna use deep down behind the scenes. So as I said, these look a lot like a render array but it also looks like a form API element, and that's because it is a form API element, which you're likely a little more familiar with the form API than, say, the render API. Interestingly enough, the checkbox class extends the form element class, which extends the render element class, which means the form API is a subset of the render API. Mine kind of blown. But hopefully, since I'm assuming we're a little more familiar with the form API, this kind of helps us understand render elements. And also to get back to the point of why render arrays are useful, I thought of this last night when I couldn't sleep. Everyone's used to using hook form alter, and in that you can do whatever you want with your form elements arrays, and that's because they haven't been turned into markup yet. So that's the whole point here. That's why we're using render arrays and elements. So that's what a render element looks like. That's what they're used for. We want to reduce repetition once again when we're building a lot of very similar render arrays. So let's talk about the last three on this list, caching, attachments, and placeholders. So like the theme property on our render arrays and type for render elements, this is an example of what the cache property of a render array might look like, how it might be used. So this allows you to cache the output of a given render array or element using the cache API. And it's probably good practice really to start thinking about caching for every render array you build. I'll get more into that in a second. I'm not gonna go too far into the actual contents of how this is structured for the sake of time, but there is a great page on Drupal.org. I don't know how easy that is to read, but these slides will be available online also. This page goes in a great detail about it. You could also just Google cacheability of render arrays in Drupal. Goes in a great detail about how you can cache your render arrays using that cache property. So that's caching. And then we've got the attached property that allows you to attach a given library to a render array. That way every time the render array is rendered on the page, Drupal's gonna make sure that whatever CSS or JavaScript or whatever is in your library, it's gonna make sure that's on the page so that your markup is gonna look and work how you expect it to. You can also attach JavaScript settings like that second line there. It's a little different than seven. It's not Drupal.settings, Drupal settings. You can attach individual JavaScript or CSS files. In Drupal 7, you probably saw a lot of Drupal add.js, Drupal add.css, those two functions. Drupal 8, you're probably gonna see a lot more of this hopefully attaching our libraries onto render arrays. And with that same key, the attached key or property name, you can also use placeholders. This is a really simple example I just kind of pulled from a documentation page, actually. I don't have much experience using them. But for my understanding, they become very important with something like BigPipe. My understanding of BigPipe is when Drupal goes to render the page, it's gonna use that cache information, figure out what needs to be pretty unique on the page, replace that with a placeholder, render the initial page, and then come back with the dynamic bits later. So that's why placeholders are important, that's why caching is also important among other reasons. Could be a little wrong about that, but that's my understanding, and that's placeholders. And this example also shows another reserve property for render arrays, which is markup. You might see this quite often when we kind of are forced to build a render array, but really we don't want to run it through a given theme hook or render element. We just wanna return some simple markup, and that's what you do with markup. So that's cache attached in markup. To breeze through the last three, weight would be, you've probably seen it in the hook form altar, weight would be if you're trying to tell Drupal what order you want your render arrays to print in, so you'd give that an integer or float or whatever. And then prefix and suffix can be used to print a plain markup before and after the resulting markup of your rendered render array. Again, there's more, but those are the, some of them are commonly used. And that's my crash course on the rest of the render API, which only leaves one thing left to talk about, and that is the future of render arrays. But I'm not going to go into too much detail about this, because if I did, my information would probably be out of date as soon as I wrote a slide for it. But what I do know is we can kind of start with looking at this old core issue queue to refactor the render API to be objects oriented. If this was the case, we'd probably be talking maybe about render objects rather than render arrays. But as of recently, there's been a lot of discussion happening that makes it sound like it's not going to be one-to-one. It's not going to be that simple. And the issue here to read on this topic is this one, which again, that's pretty dark blue. But if you Google those words, hopefully it'll show up, or again, my slides will be available. But this topic was opened by Wim Lears, and Dree's kind of touched on it today actually. And as Dree's note, when he was talking about the theme component library, I think it's called initiative that may or may not happen. That's kind of started from here. And the idea is to basically drastically alter or change or replace and simplify the theme and render system to more of a component-based approach. Being as a component-based approach is how a lot of the front-end world wants to work these days. You can kind of accomplish that with defining components with hook theme, but it often falls short, doesn't really accomplish what we want. But there's a lot of really interesting insights on this issue, not only from Wim, but a lot of big players in the Drupal community and theme system maintainers. And the decisions, of course, are complex. They're far from being made, but it does look like the theme system will end up being drastically different, which will be for the better. But that also means that render arrays, the current theme system, the current renderer API, basically everything we've learned about today may be removed from Drupal 9. And they're descended, the theme component library initiative could even be merged into Drupal core in a minor release, or Drupal 8, I should say, in a minor release. But backwards compatibility can't be removed until Drupal 9. And as we all know, Drupal 9 is probably not gonna be around for a while. And the seismic change really in the theme system is gonna take a long time to make a decision on, a long time to implement. So I didn't just waste an hour of your time. Renderer arrays will still play an important role in Drupal 8 for years to come until they're replaced. And that wraps up what I've got for you on render arrays. Once again, I like to not repeat my code, but repeat what I say. So for a quick recap, this is what our render array looks like. We've talked about how they work, where the theme key says what theme hook we wanna use and the rest are the variables, or if we're using like cache or attach, those kinds of things too. That theme hook is initially defined by hook theme somewhere. And that includes what variables we can use. And when we go to render our render array from within a template, the variables we've passed along are gonna be manipulated by whatever pre-process functions are, have been created for that theme hook until the resulting variables from those pre-process functions are printed in the template for that theme hook. And we're gonna get the markup that we want. And they're useful because they're abstract. Other modules and themes can implement their pre-process hooks to alter the render arrays before they become markup. Couldn't happen if you use the theme function. They could alter it even in the template, twig template if they wanted to, hook form alter as I said before. We can also do fancy things like pre-package, render array variables into render elements. We can use a number of other reserved property keys to do other fancy things like caching our render arrays with the cache API, attach assets to them, or add placeholders in them. So there you have it. Hopefully now we understand render arrays to go forth and use them in our projects. If, thank you. If you wanna read more about any of this, a few links. The first two though are generated from the theme.api.php that's deep in Drupal core. I'd recommend just opening up that file in a text editor and reading the whole thing. That's pretty much my presentation. And the third one's for Drupal 8. Again, I mentioned these things are very similar. If you're kind of like me and still working with Drupal 7 on your client work, start building render arrays anyway. It'll make your reporting to Drupal 8 easier and all the other good reasons that I mentioned multiple times. So thanks again. And I think we've got 10 or 15 minutes for questions. If you wanna ask them, I believe that would be what the mic is for. Oh, and again, to plug the shirts. If you want a shirt, come talk to someone in the shirts. Yeah, questions. Radiohead. He just looks very puzzled. And I'm a big radiohead. Oh, question on. Yup. Turning off the render array in Drupal 7 using the entity arrays and maybe pushing the stuff into twig now. That's a good question. I think people are trying to do that. Oh, something I guess I could plug. The Drupal twig Slack channel, or group, I guess you'd call it, is a great place to stay up to date with this kind of stuff. And in that, I think people have talked about doing kind of a hackish implementation of twig in Drupal 7. I don't know if anyone's done it super well yet. It's definitely a welcome approach. I'm doing that now for headless blocks. Yeah. I just completely turn off render, go to the entity array, jam it into the JSON settings object, and I pull it out there, and just because. Yeah, that's definitely an interesting approach. I think you're getting closer to what the theme, and I'm not repeating the question. That's bad for the recording, so I'll repeat it after this. But I think you're getting close to what Drupal 8 will eventually have in its theme system. So I think you're just ahead of the curve there, and it makes a lot of sense. And the question was, what are the thoughts about removing, or turning off and not using render arrays, but instead kind of pulling twig into Drupal 7, and. Because underscore looks a whole lot like twig. Okay, yeah. Sorry, your mic doesn't go into the recording, and I'm trying to paraphrase what you're saying, but yeah.