 Good evening. Thank you. OK, so welcome to Drupalcon Amsterdam and welcome to this beautiful city. Thank you for joining in. Sorry for those who are having a repeat session, and they have already had this introduction, but for those who are new, what? Just giving my introduction again. So the topic for this session is deep dive into Drupalator under API and using some sort of screenshots, some introductory examples to take this conversation further so that we are well-aligned. Introducing myself. My name is Surbhi Srival, and I work with Syrgium Technologies. If you want to locate my profile on Drupal, you can either search me in my complete name or hit that link on the screen. On Twitter, I go by the handle, Surbhi Srival. And if just don't forget to take this conversation live using my Twitter handle. At Syrgium, I'm primarily involved with Drupal, wherein I have worked with Drupal 7, Drupal 8 projects, which also means that I have worked with teams which have used Drupal in various different flavors. Talking about Syrgium, so Syrgium is a 15-year-old company, and it started mainly with non-Drupal stuff, a lot of ROR, Python, Django. Then four to five years later, Syrgium started getting its hands dirty with Drupal. And now eight to 10 years later, we have a good Drupal name with about 200 plus people, primarily focused towards Drupal, making us Asia's largest Drupal boutique. And Syrgium has its headquarters in Delhi, and we have people working all across the globe. So just to set the context right here, so that all of us are aligned as I skim through, I would start this talk with an introductory example. We will talk about what is Render API, who the audience to this API should be, role of Render API and how that role changes depending upon what you are trying to achieve in your project, which also means that you might be a module developer or you might be working on the front-end side. So we would check that out. Why Render API? And why not modules that return strings of HTML where we will talk about the benefits, which this API provides. Underline mechanism and how Drupal distinguishes Render arrays from other arrays that contain them. Then we would also talk about some of the main components which build the Render API, which is Render arrays, elements, cache, attachments, placeholders, and render pipeline. OK. So what this picture depicts? Anybody from the audience? Dancing noodles? OK. And? Something else? Sorry? I forgot the code. OK. Closer, closer. Any more guesses? Oh, exactly. So this is a chef, right? And who is trying to build some output, build something, right? And for his input, he is using some sort of dough with long, complex strings. And what would happen after that? Anybody? He might be able to produce that recipe, but he would end up very tired. And a lot of effort would be involved, right? In juggling with these long strings. So how we can help them? Help him. Cut it into pieces. Right. Exactly. So we can help him by providing him some standardized way to cut that long strings into some standard pieces, right? Which can produce the output, but at the same time reduces efforts. And that is exactly what Render API does with Drupal. So Render API, it provides a mechanism wherein data can be defined as structured arrays and not complex strings. And it also defines a mechanism which converts these structured arrays into a format which is well understood by browser. So Render arrays provide developers a way to represent their data into the application and also provides various hints on how to use that data. And Render pipeline is a process Drupal uses to service a request, which involves gathering render arrays from various components, determining what type of format should be, handling caching, so handling caching and caching validations, and ultimately rendering the structured array into the desired output format about who the audience to render API should be. So all of us, we are in the right room, guys. So anybody who is working with Drupal, at least at a conceptual level, should know what Render API is. And Render pipelines are less crucial. And if you are working in designing arrays from scratch, then you can have knowledge about them. Now, you must be thinking, why Render API? And why not modules that turn strings of HTML and just print them to your pages? So let's just say that you want to print a new article on your page, right? But you don't have to print it as it is. And you might have to remove the image part of it and print it somewhere else on the page. So option one could be, if that setup is all sort of a complex string setup, then you might have to create a regular expression. Remove that image part of it by exact match, which is obviously a very cumbersome process. And then print that image part into some other part of the page and regenerate the HTML, which was actually generated at the time of rendering. So this is a very long effort are involved. And obviously, your code is non-dynamic, right? So that is the reason Render API is preferred because it allows the awesome ability to encapsulate complex logic into reusable components and reduces the expensive task of making those exact matches using regular expressions. So what are some of the benefits which Render API offers? It obviously makes the job easier by helping creating reusable components. And as there is some structured way defined, so all of the modules can work together and it becomes much easier for the themes to deal with. Talking about what role does Render API play and how that role changes depending upon what you intend to build in the system. So if you're a module developer, then it is your responsibility that you define all the data in the structured arrays. And you might also want to define some of the structured elements which can reduce the complexity of the system. And if you're a theme developer, then your main task would be to alter the existing arrays and create some sort of an HTML output. Or you might also want to create some new structures in the preprocess functions. And once these variables are defined in case of twig, they can be simply rendered as variables wherein the render pipeline can be automatically invoked and the HTML would be generated from that. Now talking about the main components of Render API. So these are some of which I have listed on the screen. Let's get the details one by one. So what are some of the ways wherein we can convert the data into the markup? If I talk of Drupal 7, you might have seen there is theme function implementation which can be widely seen in much of the core and contrived and custom modules. We all use them. So this is a very basic theme implementation wherein the first argument styles Drupal that image has to be rendered and the second argument is an array which is taking the path and the alternative text information. If I talk about the equivalent render array, so this is nothing but the representation of the same theme function but it is just having the hash elements attached to that array. So we have hash theme, hash path and hash alt which is taking in some same sort of inputs and we are expecting Drupal to generate some sort of markup. If I print the output of the theme function, we can simply use the print statement and it would give a result in markup to us but can I do that with arrays? Cannot use the print function, right? It would simply return the string A R R E Y on the screen. So what do I do then? I have to make use of specified functions for that which is the render function. So a render function basically is used to display or print a render array into Drupal 7 and it would then provide this result in markup on the screen. And in case of twig templates or I can say in case of Drupal 8, you can simply print these as variables and invoke the render pipeline which can automatically create the stuff into HTML. Few things to notice about render arrays is that you would always find these as nested arrays inside other arrays. For example, on the screen, you can see a simple page array representation which has header content sidebar as various regions. And if I wish to print them on the screen, in Drupal 7, I can make use of render function and in case of Drupal 8, I can simply use page.content. So what is happening actually behind the scenes? Wherever Drupal is asked to render a render array, what it does? It just digs deep into the keys and if it finds a hash key in that array, then it considers that array as a render array and prints the output as it is. If it does not find any hash key, then it would consider it as a normal array and start looking off more and more elements to render. So hash keys are very important because they help Drupal distinguishing render array from other arrays which actually contain or encapsulate those arrays and they are basically distinguishing factor for Drupal. So I have listed some of the hash keys which are reserved properties and you can make use of them while interacting with render API. So we have already seen hash theme. Hash way could have either float or integer values and you can use it to decide the order in which you want to print your output. Hash cache and hash attached, we would see later in the presentation. Hash markup is used to just give some sort of an HTML and prefix and suffix we all know to print anything before or after the markup. Then there is another thing called render elements. So this is a very basic implementation of a checkbox class which I have built up from Drupal core which extends form element class and the output of a get info function is something which is some sort of a render array. Just to make our task easier, Drupal provides this ability wherein it defines some set of defaults for us and we just need to call those elements. So render elements are nothing but we can say that these are predefined render arrays wherein defaults are already defined for us and anything which we wish to override we can just define it and it can be picked up from there. So if you see the screen, checkbox class extends form element class which extends render element class. So form API can be said to be a subset of render API. Talking about cache property, so this is a very basic implementation of cache property of render array wherein we can see maxH tags context. So maxH could be zero, one, 60, any integer value. MaxH 60 means cacheable for 60 seconds, maxH zero means not cacheable at all and maxH permanent means cacheable for infinite time. Cache tags are something which are data dependent so here you can say node ID whenever node ID, let's say node colon five. So whenever node five changes, there would be a change in the cache validation. And then cache context is something which is context dependent. So here I have used language dependency wherein anything which varies with the context would change this cached item and just as boot practice, context tags and maxH should always be defined whether or you want to cache or you don't want to cache your element. Then these are the attached properties. So when we were working with Drupal 7, we were actually seeing a lot of Drupal at JS and a lot of Drupal at CSS which were used to call CSS or JS onto the screens but in Drupal 8, you would find more sort of this type of arrangement wherein attach, hash attached is used to call a CSS or JS to that particular page which also means that whenever that page is rendered, Drupal ensures that that particular CSS or a JS, JS is already present in on that page in the markup which it is expected to be in. Then placeholders, so placeholders are important and that is why caching is important and placeholders are basically a Drupal identifies the most dynamic parts of the page and just displays them, making them more and more dynamic. So some sort of this functionality can also be seen with big pipe wherein it define unique elements on the page, define them as placeholders and just make them dynamic at the very end. That is all with this quote. Join us for contributions and thank you for being a great audience everyone.