 I came today to talk about Higer, all the components, and it's also the journey that I follow when I was creating some add-ons. And I discovered how to compose them together and how this pattern actually helps a lot to create better APIs. So a little bit about me. That's my name, and you can find me in either of these countries or on the internet, on those handles. And I have a confession to make. I am not British. And the second one is, this is my last slide. I only have one. Because this disclaimer, there's going to be a lot of code, a lot. So I decided that to make it lighter because it's the last time, and I know the only thing between you and the bar, I wanted to make it more entertaining. And I just wanted to tell you a story through a video game. So I wanted to tell a story. This is our hero. And he came to visit his master, and his master is lying in bed very sick. Oh, our beloved thought leader ate something poisonous yesterday, and we need to save him. So in order to do that, we need to build a day picker so we can go back in time and save him. The thing is, he's very sick, and we don't have time to actually he's very sick, and we don't have actually time to build this thing from scratch. So we need to find a way. And he believes in us. The thought leader is give us his approach, his approval. And we need to learn how to compose existing components to do it on time. So for doing that, we need to learn the secrets of how to order components on his book. So let's go there. It actually works. Let's see why harder-order functions are because it's something we need to understand to understand what higher-order components are. This is the definition taken straight away from Wikipedia. In mathematics or computer science, for the matter, a higher-order function is a function that either takes another function as an argument or returns a function from it. The first line is a controversy about the second one. It's everybody who reads from that. So this is the canonical example of other components or, sorry, functions. And in this case, is this working there? In this case, the function above, it's receiving an integer, returning a function that uses that integer over there. So when you call the build other function with a number one, it returns a function. So whatever you call it with three, it's going to give you four. And if you call it with another number, it's going always to add that number to the function. And the key thing is that this is working this way because this is creating what is called a closure. This number that is available within this context, it's wrapped in this function, so it becomes private state of this function. And we'll get back to that to see why closures happens to be related with higher-order components. But this, it's fine. We have seen these kind of functions before, but I don't see how this thing applies to my components. The thing is components are essentially functional, or most of them are. Some of them may load data on themselves, but 90% of them, given the same inputs, they're going to generate the same output. The output being usually UX, that means DOM plus events. And higher-order functions are functions that return another function, so higher-order components are components that return another component from it. The key thing is components can return. As far as I know, there is nothing like a return in a component. So there is a number of meetups happening in the in-of-the-town, so we should go there. I'm going to use the mouse because it's actually faster. There is people, and you can talk with them. Let's see if this people has the answer. May, I don't know, maybe him. No. Let's talk with him. He's the Ember Engine Master, but he seems to be really grumpy today. So we decided, I mean, we owe him something. What do I owe this man? And everyone in this room does the same. We do owe him a beer. Let's talk with him again. The more you clap, the longer you stay here. So, Master Jackson, can components return values? And actually, the answer is yes, sort of. Think about the Jill keyword. The Jill keyword is a keyword that allows you to frown within a component. In here, you can perform some computations, and then whatever you pass to Jill becomes available in the block between the pipes, only within the lifespan of this block. That means that it's like a kind of, it's a temporary return. It's a return that is only available within a block. So, using this approach, that means we do return things from components, but how do I return a component from another component? And this is where a component keyword enters the game. The component keyword has been available for a long time in Ember, 2.3, if memory doesn't fails me. And it has two usages. The first one is not that interesting, but it's render a component given the string with its name. That is, you pass my button to the component keyword, and it's going to look at the component with a name and render it. In this case, with no arguments. And you pass, if you pass a bound value, it's going to look up the component with whose name it's contained in this value and render it. The second usage is the more interesting one, is the cluster component creator. It is that when the component keyword is in bulk in what I call a non-renderable context, that is not between curly braces, this component is not going to be rendered, it's going to be instantiated, sort of, and passed to either some other component, or in this case to yield. So these components are available in this block. The first one is user avatar, and you are binding already some data, image and size. So in here, when you call the component keyword again, and you pass the avatar, you are going to render this component. And those values are already bound because they were passed when the component was initialized. So the same happens with the next one, show map true, and it's equivalent to render the component with this syntax. This is the exact same thing. If we decide that we want to override the values or compliment the values that were passed on initialization, you can. And whatever you pass on invocation wins over what you pass on definition. And this pattern happens to be so, so common that there is even a short hat syntax for this. There is the hash helper. Basically, if you put these components inside an object with the hash helper, and you give it a name, you win two things. First of all, you have given a name to the component, so you are defining a public API, and you can, instead of using component and use card.avatar, you can do it shorter and do card.avatar without the component keyword because it's going to find this thing, check that it's a component definition, and that means I have to render it. Another key thing is that this approach of having components yielded from another component means each component retains its ability to have blocks. This is key. So this seems very complex, creating components, passing some values, yielding outside, so you can render them again, maybe complimenting the arguments with some other arguments. But this is a very important concept for an API design. So our hero now needs to go speak with the Hagerst Ember Priest that lives in the temple of the core teams. So let's speak with him. There. So this is him. He was avoiding for us. He knew this day would come, and we want to finish our training with him, put wash, remove wash. Wax, and the time is running out, so let's go to the topic. And this is a dear matter to me. It's close to my heart. API design is important, and not just because of aesthetics, which I agree is something that matters. It's also because component with a good API is a component that makes you less prone to make mistakes. Component with a good API basically makes you look smarter with something you want. These are some good practices. I have the style, but pretty much everyone would arrive to the same conclusions. The least options, the better. That doesn't mean that there is a magical number over which your component has too many options, depends on the component itself. But if you find that you have a checkbox and it has seven options, that's wrong. So that's one example. Another is abuse bindings to communication. So I know that bindings are convenient sometimes, but if you find yourself using bindings all the time, this is going to be a problem when you want to extend this component with some other values. Minimize the number of mandatory options. That means a combination of a configuration to some extent. You can give sensitive defaults. Options pass to components that care about them. That means when you see a lot of components receiving properties with prefixes, that means header class, header color, footer class, footer color, that's a smell. And if a component has all these presets, it should be easy to extend the way it behaves so you can reuse it in many contexts. And for that, the master give us this problem. He wants us to build the xToggle component. The xToggle component is probably the easiest component you can imagine is a checkbox with makeup. That's it. And this is the first approach that our hero is going to follow. Okay, master, I can do that. It's very easy. So it starts xToggle check equals check. We get a component with a bound value and the format or the HTML is actually simple. You have a tagless component with a UAD attribute and then you have this label that is the round thing that you can click and since the four attribute matches the UAD of the checkbox inside, which is hidden, whenever you click on this, you're going to toggle this thing which mutates this value. Simple. The thing is now the master wants us to add out to save because this checkbox is going to use to modify user preferences or something like that. That means every time you change it, you need to save. Trilling is using bindings. The only way you have to hook into state chains is using observers which can get out of hand very quickly or in a more complicated example, you could even have computer properties with getters and setters and do something, maybe some asynchronous thing but if you, for example, want to not modify this value until you actually get a response from the server, you can't. So the solution for this is well known, it's data.action.sub, that means being explicit about how the state flows. So you pass the check property and you pass a callback on chains. This is going to be invoked whenever the toggle is interacted with. So you decide what to do, which usually would be mutate the value. The only change is this thing, instead of mute change, sorry, mute check is going to call the unchained section, whatever that is, and you decide what to do, which is usually this thing upstairs, but it could be safe and safe to the server, maybe a concurrency or something like that. And the key point is that it's up to you to decide what to do when this function is invoked. The next thing that the highest priest wants us to do is these components should be available in two sizes and three colors. Seems like a win, but okay, we have a designer, we can do that. And the only thing is we now bound size and color because they happen to match the CSS classes we want. And now we pass them every time we want to change the color. Problem is we don't want to make this thing every time we invoke the components, so following the rules, because our heroes are aware of those rules we mentioned before, we decide to pass some default values, so only when you want some different value from this you actually pass color and size, so you get the same API so far. So it's still pretty minimal. Problem is now we want to add labels. Think about labels. Labels is not just a regular HTML label, the label has to toggle the checkbox because that's how checkboxes work. So for that, that means the UAD of this label has to be the UAD of the checkbox. That probably means the label should be part of the components so it has access to this unique ID we generated before. There it is. In this case, if we pass a label, we render some extra block, and that's the only change. Problem is if we continue this path, now we have label, enable notification, which is not mandatory, but this is still there. And now we have colors. The label has to have its own color. So label, label color. See this pattern. And now we want two labels. This is not unseen either. And the thing with labels when there is more than one is that the one in the left doesn't toggle now. It's always disabled. The one in the right always enabled. Each one can have a different color. And we ended up with this thing. We have off label, you bind things, on click, it changes to false the value, and it has the off label color. This remains the same. And then you have the on label, on label color, on click, and changes the value to true in this case. So this is becoming more and more complex. And now we have this API, off label, off label color, on label, on label color. And now we want images inside, arbitrary classes on the label and the switch, or you can, we may want to change both labels in one side, basically not render the labels next to the toggle, but somewhere else. So I, not me, I give up. So why is this so hard? And this is what we try so far, even if we try to be very good citizens, we manage to don't abuse bindings and minimize the mandatory options with the sensitive defaults, but we still have too many, way too many options for a select, sorry, a select checkbox, basically. And options are passed always to the top level, and we have labels inside, so that's why you see these patterns, like off label, off label color, on label, on label color. You see there is something popping or fighting to become a first class citizen. And as you see, if you want to add images or icons or something like that, at this point it's probably easier to start over. So, read it. We need to go to a creepy place and find answers, basically by messing with the corpses of other people that died before us. If you go to these dangerous places, more often than not, you actually get something valuable from it. So, let's see if we go to the react dungeon and see, I think these are the corpses of dead routers and there is some mysterious stranger that I want to speak with him. We're looking for the secret to create reusable components. And Dan Abramov happens to have the secret but he's not willing to give us the secret so easily. We need to prove ourselves worthy. Let's fight him. Again, people don't prove ourselves worthy of his secrets. And this is basically what we have. We probably shouldn't have fight him. This has been, we should have gone to medium. That said, Dan is an amazing guy and he doesn't deserve any of this. This is a blog post that Dan wrote back in 2015. So, it's pretty old. And where he explained a pattern that he found useful in creating react components. And it happened to also find this thing pretty useful for many patterns that are hard to implement with if we want to make things very customizable. And the whole blog post revolves around the idea of presentational components and container components. The idea is extremely simple. Presentational components are components that care about how things look like only. And they rarely have their own state and if they do it's only about things like focus or very UI related stuff. And also container components, which are the components that contain the logic, they load the data and they usually rely on other presentational components to do the markup for them. But they don't have a markup by themselves. So, with this, our hero has an epiphany and we think we know how to solve this pattern, this riddle. So, we're going to speed with the Grand Embrenu Master, the great one. And we found the answers. The main problem why everything was so hard is that we were working at the wrong level of abstraction. And this is something that is the bread and butter of designing APIs. No matter Ember or whatever, it's work at the right level of abstraction, abstract the things you want to hide, but not hide too much. Because that basically prevents you from modifying or altering the default behavior. So, let's recap where we were before. We had the check property and change action and then we have color blue, off label, off label color, on label, on label color. You see the pattern here. The labels are fighting to become first class citizens. And we find ourselves in a conundrum where we can either keep the components together because the logic is related or even if presentationally, labels and switches are fighting to become components on their own. Or we can separate them that would make styling very easy, but that means we have to wire everything together ourselves every time we want to use them. And the answer to the riddle is actually to do none of them, or both, in a sense. Let's see if we're applying this pattern we can get somewhere. If we decide that the top level component is going to be a counter component that is going to handle all the logic, it generates a UAD, the same thing before, but it has an action on change. That is the one that is going to, given a value, it's going to set, call the on change action outside with this value. And if not giving any value, it's going to get the opposite of the recurring one and also call the on change action. The thing is now this component has no markup at all, it just calls yield and passes two components, our presentational components, the switch component and the label component. There are, these components have been divided from the original one and it passes everything you may need, the change action, the UAD, the check property. So the component has been wired already. So this component prepares everything inside. And the presentational components are extremely simple. The switch is just copy the markup and put here the default values because this is where actually belong, the size and the color. And the external label is just a yield and it happens to be a component with a tag name label, some attributes bound. And whenever you click it, it's going to call the change action with the value passed to this component. So it's relying on the pattern component to decide what calling this action actually means. And this give us the flexibility and possibility we wanted at the right level of abstraction. So in the case of, in case we want to render just a very simple switch, we call the external component pass the check property and change action and we get something back, T is an object that has the switch component. So we call it and we get a nice small green switch. But if we wanted to make it big and red, you pass color red and size big. And you pass this into the switch because this component actually cares about those properties. And if we want a label, you use a label. You have also the label component available for you. You invoked it and it has a block. So inside there you can have text, you can have images, you can have anything you want. You can even have many labels, each one with its own color. And if you realize now there is no label color, we have color that happens to be passed to the label. And size could be also passed to the label. That means we are no longer making up names like off label color, on label color. We happens to have a label with a value false. And now the names have, sorry, not the properties have names that actually makes sense. It's not label color, it's color. It happens to pass it to the label component. And you can even put both on one side if that makes sense. Or pass some classes like italic, and you have italic things. We can even mix and match busstrap markup, tub tables, anything you want. Because now there are different entities that happens to be wired outside. And all of this may seem a bit verbose, but the thing is you don't need to use this thing, this pattern all the time. Because even if you compose the component this way, you may want to make this thing opt-in by passing a block. And if you don't pass a block, and it's something you can know by using the hash block magical property, you just render the X toggle, nothing else. And you end up with the exact same API you had at the beginning. No extra arguments, nothing else. It's like having two modes, power mode and a standard mode that you can switch between by passing a block. And this pattern enables composition in many ways that were not possible before. With very few view effort, you can allow the users to decide, I don't want your switch. It works well, but it doesn't look nice. So I want to make it different. If we make that the component queue is rendering not strings, but bound values here, switch component and label component that have the same defaults as they were before, but now it's something the user can pass to the component, you can create some crazy shit, sorry, with a bunch of CSS and you can pass this new component you created that is just markup because remember the logic is outside this component. So it's very easy for you to replace it and you can let some very crazy checkbox with very crazy animations. And you just have to have a designer next to you. So the master is happy, it's happy with our progress. We are worthy of giving the components we need to build a date picker and save our beloved thought leader. So let's see if we can, we got two components that are exactly what we need to build the date picker. We get the basic drop down and the Ember Power Calendar. And this is two components I created that follow these patterns. I kind of regret discovering these ideas after I created the power select, but it's something we can fix still. And this approach of having the drop down building two components and having no markup by itself, and same with the calendar, it can go a bit beyond and you can decide that the entire API is the object you build. So that means it has a state like it's open actions like close, toggle, helper functions, if that makes sense. And I have a standardize within my components this approach. It doesn't mean it's the best, it means the one I'm using. And the key thing is that if all of them follow the same, they have the same shape, you can do pretty cool things with it. If we think about a date picker, a date picker is nothing more than a calendar inside a drop down. That's basically a date picker. And you may or may not have an input field where you render and allow to modify the date. And this is the API of both of them. I think I have removed a few properties for fitting in the slide. This is the API of both of them. So you have actions from both and what happens if you mix them? Because there are objects and objects can be merged and you can do things with it. So how do we merge components together? It's simpler than it looks because you can render the drop down and now you have the drop down here available within the scope. So far, no markup. Then you can render the power calendar and get the calendar here and still no markup. So now we want to yield both back to the user. So you use yield and you pass the calendar and the drop down. But we said that we want to expose this thing as a single component, not as many components because we could have done this thing already in the template. So we are going to use the assign helper. This helper I created is just a helper that takes some objects and do deep merge. That's everything it has. And we can pass even extra things, like in this case, it makes sense to have a format date helper that we can use. And how do we use? Now we have the power date bigger, which is the thing we saw before. We passed the date and the change action which we remember were passed to the right thing inside. So from the outside, it looks like a single component. It received the drop down. It behaves both as a drop down, so it has trigger and content, but also as a calendar. So you have day navigation and days all together. We have merged two components and create something that didn't exist before. And you can have the input text that executes the helper, which is using some other helper because there is not such thing as contextual helpers for now. Or you can even decide that the input is not something you can edit, but you want to open the drop down with a button next to it. So at the end, you can decide whatever you want. You can have the content with circles inside because remember, each component still retains its ability to have its own blocks. So that means we are not limited to the two blocks per component idea. Now, we have many components. That means we have two blocks per component and we have split this thing into four things if I'm right. This is the result. The Ember power is bigger, which by the way is something that actually exists to go to GitHub. So now that we have everything we want, we can go to the past and save our thought leader. So he's not here yet. So let's see if we can find the Poisoner's Root and save him. By the way, this is the Portland Tomster. What else? And this is just the beginning. There is a lot of things you can do with it. There is many, many patterns you can follow. I'm going to mention one because I like it a lot, recursive components. This is, you don't need to actually pay a lot of attention to this but you can actually render the same component within that component following like a stir. You can render as many labels as you want and you don't need to pass all the options every time because if you render the same component, the same options you pass on the initialization are reused. So you only modify a few things and you get the new context. So you can render things like nested menus and a lot of things and that's everything I have. How is time?