parents welcome to this parenting webinar and had a parent with more ease and calm from a done without the burn out. I am yesterday son of parenting coach and educator serving this beautiful Muslim community and I'm so excited to be here. So many of us parents can agree that parenting is a 24 hour seven days a week job that doesn't stop including our middle on struggles. Let's be honest, our children will still need we'll still refuse to eat their breakfast, take hours to get ready in the morning as we juggle the many responsibilities of time and constantly keeping them occupied. We can find ourselves feeling emotionally triggered for our children's behavior. Quite often we end up feeling overwhelmed and frustrated by our Ramadan experiences. Especially coming out of the pandemic where there was no escape from the constant stress, misbehaviors and exhaustion of juggling so many responsibilities without extended family help and community. So I have a question for you in the month of Ramadan. Do you find yourself feeling physically spiritually or emotionally depleted at the end of your fasting day? Do you feel there's not enough time for your Ibadah for praying for reading Quran, etc? Do you find it challenging to empathize with family members who have short tempers? Or are you trying to do it all by two lists of yours? And it gets difficult to feel the Ramadan experience. Great, you're in the right place. Yes, Ramadan has incredible blessings. And but it also comes with unique challenges for us mothers. Continue. I am so excited to spend the next hour with you in this webinar. We're always sharing some some insights and tools to start shifting your parenting from overwhelm, burnout, to feeling more calm, and not having the regret or burnout a lot of parents feel during the month of Ramadan. So great. So happy to have you all here. I will cover the two keys for creating more ease and calm in your Ramadan journey.  I've had the beautiful opportunity to work with countless families over the past decade. I've worked with over 100 plus mothers, empowering them to step into their leadership roles, learning how to manage their big emotions, and cultivate positive parenting mindset all the while modeling the prophetic way of love, mercy, and patience. I've taught from East Africa, Kenya, just in California, hosting workshops, teaching life classes as well as coaching one on one in groups. So I'm so excited here to have for all the participants a link that I'm providing at the end of the workshop. Over the years, speaking loss of parents and my own experience, parenting while fasting and fasting children can be quite challenging. I found you have a Ramadan plan and reasonable expectations. Things go a lot smoother for them and for us. That's why I'm providing you a list of 20 screen free activities proven to give your kids engaged and persons participating in Ramadan while having fun and building lifelong family memories. Insha Allah. So this is my disclaimer that this isn't a magic formula found in this webinar, guaranteeing the perfect parenting, nor are you going to understand everything you need to know about creating more calm and easy parenting. But what you will learn today are some crucial insights on effective parenting approaches, women experience mentor and learn some amazing truths truths that will help give you food for thought. So as the parents are truly appreciate that you made it to this webinar, despite your many responsibilities, give yourself the gifts of living present by turning off all distractions, phones, closing any other windows or television, really allowing yourself to gain whatever it is you intended to want to get from the webinar today. So now let's go ahead and get started. Let's remember our Islamic perspective and recognizing our children are an amana, a gift from Allah to guide and to say keep. Yes, we are responsible for filling this trust to the best of our ability. It's our duty as parents to create loving and connected relationships with our beloved children so we can guide, teach them and say keep them. Parenting is any bad that form of worship by beautifying our intentions and setting our intentions and then taking action. There's a great reward with the law out of this divine generosity. This really includes every diaper we change, every time we wake up to put our baby back to sleep, every lesson we teach patiently, every time we give our teenager the benefit of the doubt, not exploding on them and taking it personal, but setting and setting firm boundaries and giving understanding. All can be forms of a bad that with setting intentions. Also, it's always blessed us with so much influence of our children, especially in the early years. So by stepping into our leadership, more calmly, lovingly, yet firm when necessary, we can effectively parent our children. So it's getting to key number one, three mindset hacks to remove overwhelm and make the most of your Ramadan. This inner work of parenting starts with acknowledging our mindsets and our emotions. The inner work is such a beautiful part of our parenting journey as one of my parents by the teachers has said it is the opportunity that Allah gives us to refine our character in the most beautiful ways by aligning it with a prophetic model of love, mercy and patience and our interactions and so much more. So what are parenting mindsets? Quite simply put, mindsets are the thoughts and beliefs we hold about ourselves, our children and the circumstances that Allah spontaneous put us in. At every moment Allah gives us a choice as to which thought and beliefs, which thoughts and beliefs we choose so we can choose and these thoughts and beliefs drive our actions. So examples of negative unhealthy parenting mindsets would be believing that parenting is so hard during Ramadan. Believing that kids just don't listen these days or often hear, I can't manage to parent and enjoy my Ramadan experience. You can only imagine believing any of these things would affect your emotions, have you feeling sad, overwhelmed, probably resentful and then how would you behave as a result? You may not find solutions to how to manage your energy, how to create more energy within you, how to parent a little differently so your kids are able to listen better, are able to cooperate as they're expected to. So really shifting unhealthy negative parenting mindsets is the beginning of shifting our parenting approach. So the first place starts as we said is by taking back our thoughts. Allah has given us the capability of taking back our thoughts which inform our emotions and these emotions are what drives our actions. There is no compulsion and we get the opportunity to take it back at any moment because the reality is is no one is forcing us to think what we think, to believe what we believe, no one is forcing us to feel what we feel and no one's forcing us to act how we act. So for example if a parent was to believe my child never falls asleep unless I'm with her, I have to sit with her, I have to rock her to sleep, I have to sleep with her. A good place to start will be asking your question, asking yourself a question. Is it true? Is it ultimately true that my child cannot sleep without me? And is it possible at some point that she can sleep by herself? So what's key here is asking the question, questioning the beliefs, they really aren't serving us and this opens us up to new solutions to our parenting challenges. Calm and our parenting is crucial more now than ever. Having entered the bus a month or a month, we have the opportunity to reset ourselves on so many levels spiritually, mentally, emotionally, physically and provide a different experience of being together as a family based on cultivating more calm and more peace.  My child would just listen, I could keep my cool as a parent. In reality, managing our emotions is what makes us peaceful as parents. When a child feels to do what we expect them to do, we often lose our cool and become angry and frustrated whether they spilt the milk, ran into the street or hit their sibling. By questioning the belief and reframing your thoughts, you can better manage your emotions and therefore your behavior. This encourages us to instead focus on working together when we're calm, to find a solution instead of being reactionary and getting angry or just got consequences in the heat of the moment. As I said, we do have a choice however difficult it may be in the moment. So good news, we have three simple mindsets to create more ease and calm. So the reality is that every day we're given this opportunity to make new choices by Allah when we're taking responsibility for our mindsets and emotions that drive our parenting actions and we can then show it more calmly and effectively in our parenting and really feel good about the choices and the approach we take. Mindset half of the one, go easy on yourself because we all know perfection is for all of us once out of love. There is no perfect Ramadan plan, there's no perfect experience. So go an easy on yourself means showing yourself some empathy. Wherever you are in your current phase of life or season as a parent, you're juggling, you're juggling a lot of different roles. So be easy on yourself, not hard. Go easy on yourself means striving, striving to your best and trusting. Trusting your best is all Allah expects of you.   Wherever Allah has placed you is just right and perfect for you.  We're in different places on our journey. We have to bring capacities in different forms that we bother that we're able to take on and strive to fulfill. By taking this pressure off of ourselves, we'll feel less regret about needing to do more, especially in the month of Ramadan. But then we can start tasting the sweetness of those moments of connection with Allah throughout the month of Ramadan. Mind said hack number two, get curious not furious. When we approach our children in a furious state, it causes harm to the relationship because they are confused by all our upsetting emotions and they can't hear the lesson and when we're in that state there really is no lesson learned. What we can do is reframe the situation because we do have a choice. A choice either to allow our emotions to hijack us, our emotions, whether it's anger, frustration, disappointment, and explode these emotions onto our children or we can take a pause, give ourselves permission not to respond to the moment. It can start with taking a deep breath, doing some thick good, reminding ourselves not an emergency, and the next step would be getting curious about what's really going on for ourselves in this moment. Here are three ways we can check in with ourselves. First we can ask ourselves what am I feeling and being honest with ourselves. Our feelings are a wonderful sign. They're a wonderful indicator to get us to knowing what we're thinking about what's happening. So we're feeling connected to what am I thinking? What am I thinking about myself? What am I thinking about my child? What am I thinking about circumstances? Lastly, what do I need? What do I need for myself? These simple reflections can dramatically make the difference. So you can shift from a furious state to a more calm state. It's more effective and a loving approach in your parenting, really more aligned with the prophetic way of showing gentleness with ourselves and with others.  Like the time it took 20 minutes to find my daughter who was hiding behind her dresser because she was still in one of her school that day. Oh yeah, in the moment I was furious, even though I can laugh about it now. What I've noticed is that it is when, what I've noticed that it's gotten easier. It's gotten easier when I show myself my empathy. In that moment I could have been asking myself, why do I feel so much pressure? Why am I so upset with her? What do I feel as if she's not listening? What does that mean? And if I tended to my own need for that moment to reassure myself that it was going to be okay first, it really helped.  It's really about catching yourself just one time and creating this new inner habit. And with the last help, as many moms I work with, this can happen to you too. So next time you feel the anger bubbling while your parenting, I invite you instead to take the five minutes to get curious, not furious. Mine said hack number three. Lead by what you do, not by what you say. We want, if we want to have more calm and ease and to reduce the exhaustion of parenting that's common, it starts with us modeling ease and calm in our interactions with our beloved kids. And yes, so starts with no more nagging, yelling, or shaming our children. I recommend instead when dealing with our children's upsetting behavior, taking that pause, hitting your pause button, putting the space between you and your baby emotions, and how you respond to your child. As parents we have a prerogative, we can always circle back around, we're feeling more calm and in the driver's seat. Then we can discipline more effectively. By pausing and not reacting, we're modeling beautifully good character. How they themselves can respond in those difficult moments, to life's frustrations, disappointment, and anger. Our modeling is so important and precious to our kids. Secondly, by less directing, correcting, ordering our kids around, basically helicopter parenting, we can shift our focus to what our plan is, it is we made, and those expectations we have for our kids, and helping them with their routines, and if need be, giving them consequences when necessary. This really reduces the main source of a lot of parenting exhaustion. We can take these steps to create so much more sequela, peace in our home environment. So let's go ahead and get into key number two. How do we encourage our children to fast and actively participate in the month when we're done, while having fun and building long life memories? Our kids need our support when fasting on all levels, spiritually, emotionally, physically, in turn we'll discuss four ways to support and encourage our children. It starts with acknowledging acknowledging that our children are young and as that as so they are not required to fast and treating it more as a training time, or training them, helping them develop the habit, develop the behavior of fasting, so perhaps for a five-year-old that may be fasting from lunch to snack time, and then from snack time to iftar, or perhaps for older kids, maybe eight or nine or ten having them fast, and then if something comes up where they're getting a headache, or they need to take a little medicine for a condition they have, allowing them to have something small and taking care of their need, and then reminding them that they can reset their intention, and then they can break fast with everyone else later, which really does build a certain amount of confidence and positivity through culture our kids are treating this as a training, a training when they go into adulthood and then they're required to fast. So second here is organizing a schedule. The more you have a plan to occupy, the easier things go. Having a framework for your day, it may be a loose framework, it needs to have flexibility because it's the month of Ramadan, things go a lot easier if the kids know what to expect. Next, knowing your child, each of your children are different, some of your kids may require more sleep, even more food, fluids, or drinking when they're fasting, so being able to help set them up for success and helping them take care of those needs that they have particular to them. Last is praise their efforts. When our children are fasting, we should never, never ever criticize or show disappointment, they just can't maintain their fast, but the opposite should be happening, we should be acknowledging their children and they're learning and they're doing the best of their capacity and we are so, so, so incredibly happy and proud for them to gain Allah's pleasure, because it's counted, it's counted for them as children, which is such a blessing from Allah. So now we're going to get into three steps to support our kids, without having to nag, yell, or shame them. So first step is stepping into your leadership by setting up clear expectations, expectations, routines, and schedules during the month of Ramadan, and enforcing them and leading them by your example. So if you're minimizing screen time for them, then it's important for you to minimize your own screen time and you do use that time to bless your child with more of your full presence more often, by providing our children loving connections, unlock the positive interactions throughout the day, not all day, it's just doses sprinkled throughout. We're providing these positive loving interactions that kids so thrive on, as was the way of our beloved Prophet Muhammad, so Allahumma ne'ayhe wa sallam, he showed love for true and everything he did, therefore he was able to open up their hearts for his beautiful guidance.  Our beloved Prophet Muhammad, so Allahumma ne'ayhe wa sallam, was the most realized in all of the five love languages, words of affirmation, acts of service, gift giving, quality time, and physical touch, are the five love languages that our kids all benefit from. So now it's time if one feels there's some disconnection with any of their children. Disconnection shows up and perhaps us not have an understanding between us and our children, perhaps an unwillingness for them on their part to do what they're told, or just straight out resistance to your guidance. Those are all signs of disconnection. However, Ramadan is a beautiful opportunity to connect with your kids for the sake of Allah, yourself, and your family. So step two here is having a Ramadan plan. Parents don't have a plan, it makes it much harder to guide and teach our kids, teaching life lessons, Ramadan in particular, any life skills, characteristics, and so much more. Daily Ramadan routines and schedules including includes things such as wake-up times, chore times, Ibadah time, what they can do on their free time and when it is. We don't have some sort of framework for them to follow. We can easily resort to click fixes like allowing them lots of screen time, which doesn't really lead to effective parenting because they're not involved or connected to the family or us, but it also prevents them from having the opportunity to enjoy positive family interactions as they fast in the month of Ramadan. And this is where the memories are created and those little moments and exchanges and jokes. This is where the feeling of joy and happiness, excitement, peace, and so much more happens. Ramadan can be a time to jump start these loving and peaceful relationships with our family. So lastly here we're talking about providing alternatives to step three. Part of having Ramadan plan is providing activities that will really enhance our children with that experience. Yes, moving away from screens means doing something else. And as I said earlier, I'm providing a handout called the 21 screen free ideas for kids during the month of Ramadan. It's an amazing list of so many simple things that can be done that don't require buying things and require lots of hours. I'm going to go ahead and share a few things on the list. The first section here is independent and quiet time activities that you can plan ahead. It's important for the kids to have downtime to rest their bodies at some point during that fasting day. So having them read something whether it's an Islamic book or something appropriate for them to read is a good way for them to engage themselves in some entertainment and some fun. They can listen to audiobooks. They could sit quietly and do some drawing or some coloring or quiet toys. I remember my daughter's really enjoying up until a certain age Legos. All of this can be really enjoyable and something they can do quietly. They give their body a rest and they'll also get you a break. So planning ahead that sort of thing. Then there's also you can have them do fasting crafts that encourages their creativity in Ramadan. So whether they make a menu for the family for Iftod would be one one fun crafty thing to do. Another one we're making in Ramadan placements for do our cards to post. And that's a wonderful way of remembering making a do our card decorating it and posting it. All of those things help them. InshaAllah be able to participate. Next we have family entertainment. It's something lighthearted as a family and fun. Nothing perfect here.  I do recall when I was growing up that as a family we would create little poems to share at the dinner table or we would have these jokes for you to tell or we could come up with a short play just for each other as a family. So it was very very lighthearted and very informal. You could also have the kids play card games or board games in a fun lighthearted way so they could enjoy each other. Another great way would get them involved would encourage their participation in meal preparation and serving. They could set the table. They could decorate the table. They could help prepare the meal. They could help wash the dishes. All these are wonderful contributions and knowing they're getting a reward for it gets them motivated, gets them involved as a family. Of course another really important one would be Ramadan inspired activities for family bonding. You could be reciting Qur'an or doing thicket together, reading a lot of hadith and discussing how to implement it, making a family list of things we're grateful for and thinking a lot into our there's so many wonderful things you can do as a family, daily or weekly that really will enhance Ramadan experience and create traditions. Last but not least outdoor time is essential getting our kids moving off the screen and out the door doing energy busting activities because they have energy. They're kids. They're spike writing, taking a nature walk, jump roping, or even delivering a meal or a gift to a family friend or neighbor. There's so much one can do in this blessed Ramadan that it can be fun, they can be engaging. It doesn't require a lot from us as parents. So thank you so much for saying until the end. We'll come to the end of the webinar where we focus on resetting and implementing a neurobiased mindset which will really allow you to change your perspective and therefore support you in changing your actions for the better. It's been such a pleasure being here with you in this webinar and I so appreciate you attending and investing in your precious time and efforts towards improving your parenting with Nila. So to access this gift just use the link provided on the screen for the checklist and you can post it on your refrigerator for easier reference or you can use it to plan your daily activities during this blessed month. Just use the bit.ly link provided there. InshaAllah it's my hope for you that the blessed month will enable you to become closer to Allah and receive his immense rewards even if you're parenting your children. Have a blessed Ramadan and may Allah be with you.


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.  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 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.  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.  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.  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.


So Detroit is the story androids in the near future. The game takes place 20 years from now in the city of Detroit in the US. And by then, technology has evolved to a point where there are androids that look, move, speak exactly like us. So we treat them like machines, because we created them. They are just advanced machines. But actually, the story starts at the moment where they start to open their eyes and feel conscious. And they are going to start fighting for the rights and wanting freedom, of course. So for us, the goal was not just to do sci-fi. It was not just to imagine a very distant future. It was much more to imagine our world and imagine what our world would be like with this kind of technology available. David, what did you draw as a general androids that appear in Detroit Become Human? Well, the starting point was really to have androids that would look like human beings exactly.  So we thought that in this future, people would like to have androids that look like humans because it's easier to have them in our environment and to collaborate with them, to accept them, because they look like us. So they really developed very complex things, like even blinking the eyes or emulating breathing, although it's absolutely not necessary. But it just feels like they are closer to us. So that's really the type of things that we imagined. Thank you very much. Yes, exactly. And of course, they are very advanced tools because they can do incredible things. I mean, they never sleep, they're never sick, they never complain, they can memorize everything, they never make mistakes. So these are big difference with human beings. And it's something that is worrying and at the same time, very, very interesting. So we tried to explore really what would be the impact of this technology made available on individuals, but also on society. And we did a lot of research. It was not just a creation of creativity, it was also something that was very documented. So we went to meet scientists in labs. We really did a lot of research in order to understand what we could reasonably expect and what kind of conflicts would happen with this technology available. So that was really the starting point of Detroit. And yes, I mean, technologies like ASIMO, for example, were very interesting because at the same time, they're something very human in the way these robots move. But at the same time, it's not exactly human. So I was very interested in that. And another starting point was probably the notion of dilemma, one of the very interesting questions with intelligent cars is, how is the software going to deal with dilemmas? Like your car is confronted with a very dangerous situation and there is maybe one pregnant woman on one side and maybe a group of people on the other and your car needs to decide who you are going to hit. I mean, as a human being, we would make a decision instinctively, but in this case, what will the AI decide? It's really a dilemma. And the notion of dilemma was very interesting for me in the context of Detroit, but also in the context of machines. What would machines decide in these kind of situations? Another question I'd like to ask is about Android. In this Detroit product, there is an Android called the parallel body. What is the parallel body and what is the Android like? Yeah, of course, something has to go wrong. Otherwise, there is no story. So what went wrong is that we imagine something that we never really explain. We don't really explain why some machines starts to rebel, start to feel fear or anxiety or anger. There is probably a trauma in their past, triggering this reaction. We don't know exactly how it works. We can see the image here where they break their wall of instructions, suddenly they become free. We don't know if it's a bug. We don't know if it's a natural evolution just because AI becomes so advanced that there are some procedural things happening, some code that was not written by anyone happening and making these androids want to be free. And I think that's a very interesting topic because sometimes people are really concerned about what we program with androids. But I think the most interesting thing is what we don't program, what will be the emerging behaviors with androids. And there have been some very interesting experiments with AI where, for example, they allowed two AI to invent their own language. And the two AI started talking to each other and up to a point where human beings didn't understand anymore what they were talking about. And I think this is very interesting and very intriguing and very scary somehow because they will create their own dialogue and start to talk to each other, and we won't understand what they're talking about. Maybe they will be talking about us or maybe they will be talking about Android things, who knows. And I think everything that is emerging, that was not programmed, but that happened, is something very intriguing to me. Yeah, no, exactly. It's suddenly they don't behave in a rational way because what do we expect from a machine and from AI is to be rational. So we all have our definition of what being rational exactly means. And it can mean many different things. But in this case, they start to have behaviors that would become irrational, like even emotional. What if they became jealous? What if they could feel fear? How would they react to that? I mean, for me, that's a very intriguing question. Thank you very much.