 Good, so even though the talk is called advanced component patterns, I'm going to start it off very simple and low, and then we're going to build up from there to some fancy stuff. And to all the like the React hipster people, yes, we are going to talk about render props. So I'm Siddharth. I do open source stuff sometimes. I also teach React. So if that's something that you're interested in, find me later. So the interesting part, and we've talked about this a lot today, which is the interesting part about React is that it's a really tiny API. It's pretty small. But the React community makes it like super huge ecosystem. And there's like something new happening in the ecosystem every day, especially if you're like active on like things like Twitter or Reddit. So I'm like incredibly online. And it's not a good thing, but you kind of get to see a lot of different patterns emerge every day. So I have this fear of missing out. I must learn all the React patterns. I have to know the best way of doing something. So I did. I learned all the patterns until yesterday. Of course, something new has already come out by visiting here. And you don't know that. But until yesterday, I'm going to give you everything that's going on. Cool. So there are seven component patterns that I'm going to talk about. We started off very easy. There are some context. I work for this company called Auth0. They make stuff for developers. They have a React story going on. I work in this team which has both designers and developers. So I kind of work in the middle of this. We have a whole engineering team. We have a design team. My team kind of works in the middle of this, right? That's a really interesting space because I kind of like doing both. So we do this thing where we take inventory of our application. We have like these pretty forms, buttons or those things. I'm sorry. You can't see some of the fancy gray borders, you know, like designers. But what we do is we kind of figure out what are the repeating patterns across the application. And we try to build it once so that other people who are not so design friendly don't have to do it all over again, right? Fancy saying we make buttons so that all of the other people don't know how to make buttons. They can just use our button. The other interesting point about this team is that my manager is actually a designer. How many of you like working with designers? Like as a pillar. This raise of hand. Wow. That's like barely 10% of the room, right? So imagine this. This is like a fun thing. I report to a designer, right? So it's kind of fun. But I keep like this guy, this guy, I repeat his name multiple times. He's called Fernando because he's like Spanish and stuff. But like I just call him fur because it's smaller. So fur is pretty cool, right? He's a pretty chill dog guy. He gets coding as well. So that's cool. So we started working on this project where I said that, you know, everyone uses input boxes. We need one of those and the cool is added input box. I know what to do. I'm going to create a component which is like, we take some props, but what it really does is just fits out some JSX, right? This HTML, JavaScript, you think, and then you render it, you say text input and you can pass on placeholder and other things like that, right? And for this, for simplicity, we're going to say it uses class names to style things. It has a class name input, right? Simple enough. So it comes back and says, you know, we also have some read on these things, right? How should people use that? So we go back and we say, okay, how do we want people to use read on it? A pair has to be like nice and pretty. So we say, let read only your prop, right? If somebody gives me read on the other prop, configure the class names and say like, if props.readonly exists, if it's the boolean is true, also add class name readonly. So this is kind of how it works. Also, just for good measure, you also pass readonly so that HTML can do its thing. This is known as a functional component. It's essentially a function which returns some JSX, right? This is what React folks call a functional component, right? So just to get like a feel of the room as to how should I paste this talk, how many of you folks already work with React? Just to raise a fan. Awesome. Just to click, it's really done. So I have to like really focus. How many of you don't work with React? Good. How many of you would consider being an advanced in React? Good. Okay, now I know what to do. Good. So I get functional components. Everyone's happy. Let's move on. So first comes back and he says, there are some fancy UI where while you type stuff, we also need to show like this label and how many characters have your type. I'm like, cool, okay. We basically need some state thingy going on. So let me add a span which shows how many characters, zero characters. And to make it handle state, I have to now switch it from a functional component to a class component. Classes where you have state it and construct it and all that. So if I use this dot props now, I can't use props. And then I add a constructor, which I start with length is just like zero to begin with. Instead of saying zero character, it is with this dot state dot length. And then I have to add an on change and find it with the input box. So that my change happens. This function gets called and it says, in the state set length as event dot target dot value dot length. What it's doing is as you type, it just reads how many, what is the length of the string you have typed and puts it into state. So this keeps going on and then state dot length updates, it works. It's cool. I hope you guys can read the code part of it. The UI is okay. It's just like pretty gray boxes doesn't really matter. It's your type. It changes. So this is a class component. It's not a function. It's a class you get to attach some events like on change. Moving on. This is something that really grinds my bones. This bind thing that we have to do, no matter how many times I see this, I always forget to add this. And I know why it exists. It's important. This and prototype and JavaScript you have to pass it. I don't really care. I just want to do something which seems obvious. Luckily, we can kind of get rid of this. We can just say this turn on change. And instead of saying on change as this kind of like a bracket function, you can change it to an arrow function. On change is equal to event slash arrow. And this is like the ES6 arrow function. The fun part is ES6 arrow functions handle this differently. They don't really care about prototyping inheritance and all that. They just ignore this. So you don't have to do the bind nonsense. But this looks weird. This is not how class functions are supposed to be. This is kind of awkward. The fun thing is this is like a new syntax. And you can use it. Another thing that you can do with this is instead of writing all of this boilerplate super props. This is also something I always forget. I add a constructor. I forget to call it super. I try my state and then react gives me a warning. And I go yes for the thousand time super props. And if we have to do this every time, why are we even doing this? Why is this not automated already? So with this new syntax thing, you can also do this. You can just say state is equal to whatever the initial state is. You don't have to do super constructor all of that. It looks pretty. It fits in my slide. It wasn't even fitting. Now it fits in my slide. That's the most important thing. So people call this the class properties transform. These are like additional proposal to how JavaScript classes should be here. And you can get a bevel plugin. You can use it. Good for us that create the act up already has this in print. Most of us never really have to worry. We can just start using this nice syntax. So people have different names for this. Some people call this ES7 classes. Some people call it ES next classes. It's not in the official spec yet. It's still a proposal. That's why we're doing all of this bevel magic. But then it's like a ES something. ES next class. So coming back to this text component. So of course when it comes back for the designer, that's what they do. He says, I like this thing which we haven't done. This looks like form labels. We always need labels. So let's create this email label and thing going on. And then he gives me like an interesting thing which is emails are supposed to be lowercase always. I'm not sure that's true, but in this situation, hypothetically, emails are always lowercase. But people are going to type what they're going to type. You can't control people. So when they type uppercase, we should convert it to lowercase. And you see in this in places that people say only caps log is allowed. Sorry, only capitalized letters are allowed, block letters. And you type small letters, they automatically convert it for you so that you don't have to do all that nonsense. This is something that we wanted to do. When you type big, you're going to make it small. So this is our input component that we were planning this. This component that has an input and it basically just renders the input thing. This is known as uncontrolled component. React doesn't really control any of its content. The HTML DOM does. When you type something, it's the browser's responsibility to render it into your input component. Actually, paint it into the component or keep it. Sorry, I'm a little sick. I'm going to keep coughing the entire time. So if you want to control this input, we need to make it a controlled component. How we do that is that we say state. We need to control it. We have a state for the input box. The state initial value is just an empty text. And instead of HTML, more like the browser controlling the value, we're going to say value is this.state.value. And now we control the value. The state controls the value. The funny thing that happens here is if you try to type something now, React is going to get rid of it. Because the moment the browser has it, React is going to say, no, state value is just blank. I'm going to reset it. You type it, React makes it go away. So if you want to control things, you also have to add your own onChanged, which sets the state and renders the actual element. This is a good case for us, because what we really want to do is this. We want to say, whatever you type, I don't care. I'm going to do lower case set and then set it in the value. So this is a controlled component. That's, I think, the third or fourth component pattern. I'm going to do fast and I'm going to slow down. That's the fourth component pattern. So if you want to play around with inputs, forms, that kind of thing, where you want to control the behavior of them, not just leave it to the DOM, what you need is a controlled component. You control the state, still it sets the value, and then you handle whatever you want on onChanged. So when somebody types this, it becomes small. You get rid of it. All right. Fourth comes back. Fourth is very active. First is, I like what this label thing is going on. We need the same label on address, this thing, text areas as well. This seems like a repeating pattern. We're going to use this label on everything. Every input type is going to have a label. We'll have select, we'll have switches. All of those things will have the same label. We should probably make it generic enough. So what we do is, we can do this thing called like a wrap it in this function thing. When I'm saying the internal component is still the same, when I'm saying, render it with label, and then I'm mentioning what should be my label name in quotes, which I'm giving it as a parameter. How this works is you say, you actually declare like a function function. It takes two parameters, the label and the component, and in this basically I'm saying, I have a form field, I have the label, I put the label name from the parameter, and then I just render the same component. So I don't really care in this case, what is the component? You can give me a text area, you can give me your input, select box, whatever. You can give me like a button. I don't care. I'm just going to render it blindly. So this pattern where you take a component as a parameter, and then add things to it, and then return JSX again, which is kind of like return other component, is one of the higher order component. These were all the rage last year, and now nobody likes them. This is just like disaster everywhere. We adopt a new puppy every year, and the puppy is cute, and we love it, and we take it everywhere, and I show it to all our friends, but then time goes by, people use the puppy in weird ways, they feed it too much, they take it everywhere, and now the puppy is ugly, it's like one hand is broken, it's fat, because everyone's feeding it, and now we don't really like the puppy anymore. Dogs are not cute, puppies aren't cute. So then we basically go and get another puppy, and forget about this. This is what happened to higher order components. Anywho, they're great, they're still great, they're pretty useful. So another way of using this is instead of saying with label as a function, you can also create with label as a component. You can say, I'm going to wrap this in a more component, you have a JSX form. So I say with label, and label address is the prop, and I'm literally just wrapping, nesting the internal component over here. How the code changes is, instead of doing all of that, we just say with label is now a functional component. It takes props, and it renders the label, which should be props.label, and then after that, it just renders props.children. So again, the children part is just transparently rendered. You can put a text area or text import, select box, doesn't matter, props.children, that one line is going to render everything in between over there. So these are like two flavors of higher order component, which are pretty useful, right, for repeatable patterns. Okay, so now, now for the beginning somewhere, right, we have the switch, switch the label works, thankfully we have like a generic higher order component, then we also have this like form everywhere, which has like a same changes, and if you have a button, it's border in between, right, and this is like a pretty strong pattern, right. So how do we tackle this? The first thing like let's just try to render how we would do it in like normal, what we have till now. So you put a form, inside the form you say with label address, let me just show this back, right, we have email address, and then like switch thing, and then button. So we render like a form, inside the form we say with label address, put the text input, we say with label address, and put the text area, like the big one, then we put a label, the accept, and put the switch, right, and then we put like two buttons, inside like a div, with the class actions, then we can have that nice border, and then, so this works, right, like you put two buttons, one is primary, one is normal, this kind of works, but if you see, you still have to write a lot of code, right, how can we make this simpler? After all what they want to do is for people to make forms the same way, like everyone, when they want to form, they should create a form that looks the same, like the entire company, that's effectively what my team does, but if we do it like this, it's prone to mistakes, it's prone to creativity, it's not as rigid, right, or easy. So what we do instead is, we start abstracting things out, right, we try to like compose them nicely, so what you do is, you have a form, which is one the React component, and then you have form.textInput, right, the fun part, this is something that I recently came to know, is that you can actually have components attached to other components, right, because form is like, a React component is still a JavaScript object, and you can add keys to it, so you can say form.textInput, and this text input is like one text input component which has the label in build, right, so you don't have the with label stuff, you can just pass label as a prop, and internally you can do all of those things, similarly you can have form.actions, where you say this is the primary, this is the secondary, notice you don't even care about the color and stuff, you just say I have two actions, this is the main one, this is the secondary one, and then the system, the design system takes care of which color, what is the alignment, etc, right, so this is known as the component component, this is my favorite of all the patterns because it's so powerful and it's still so easy to use on the surface, so let's see how do you, how does the code for this look like, so first of all you have the form, form is just like a stupid form, it's like form HTML and it renders everything that comes inside it, right, so this props.chill, for this form.textInput what we do is we say form.textInput is props.returning.jsx, it's a react component and inside it we say withLabel, so even though you asked for a text input when you say form.textInput we assume that using it in a form you also need a label and we take that label name from the props, so props.label, placeholder, all of that, same goes for the text area, text area becomes withLabel and a normal text area, so the API looks like this but it gives you all of these, same thing goes for action, right, you look through or you look at what's the primary, if there is a secondary and you put a button primary and you put a button normal, secondary, whatever right, so yeah just writing this much code generates this out for you and there are some key things that I want you to notice it's how everything is like, all the inputs are supposed to be aligned, you have your labels on the left side, you have this border thing going on, the save changes is not aligned to the label, it's aligned to the input, right these are not designed decisions that are baked into the form but when you look at the API, you're not really thinking about the alignment, you're just thinking about what input do I need from the user and this is the real power of compound components, they hide all of the decisions behind them, so that people who don't have to care, shouldn't have to care another fun thing about this you can actually change the underline design without changing the API, right, so when you see text input, when you see label comes with it, in the future we can and we kind of are going to do this, is we want the labels on top, we don't like them on the left, we want them on the top the fun part is, we can change the underline definition and roll it out to people and they don't have to change their code but they get this new design right, so these kind of things are very powerful because the god knows how difficult it is to roll out design changes to all of your applications at the same time, like keeping them consistent, this is a pretty good way of doing this alright, back to this concept, remember this one with the one with counter characters I'm going to put it on the right because I don't like it on the left, right and Fur is not here to stop me, so I'm going to do what I want, it's on the right now alright, so a few people started using this and they use it for project name, right, they have a firm which asks for the project name, they have this nice label and what they do is, they have a character limit on this, so when you type like really long, it gives you, like after a time this character count becomes red, right, it's how a lot of like counters work right, Twitter works the same way, it starts showing you like a red thing that you can't enter so many things so they were like, can we do this and I'm sure it seems reasonable right and seems pretty easy too what I can actually just do is inside my onChange, I can just add like a new error state which says if the length is greater than 30 it's an error, right and then add it to the state and then change the class name or whatever, use some style, right, basically I have logic in my component, you know fine, I can take care of this to make it generic, I can say let's not do 30, let's say props.limit right, different fields might have different limits, how you use this is you say text input limit is 30, right, and now it works it seems pretty good next they came up with this thing and they're like, they're optimizing the UI, right, now we have more time, we're going more UX practices, so when you type a lot of characters but not 30 yet we show this 28 characters but it's orange so we show this like orange is like a warning state, it's not error yet, right, so before 25 it's all like green or black like normal state, 25 to 30 it's orange and after that it becomes red, right, can you do that for us? I can, I can add whatever I'm going to do, I'm going to say error limit or warning limit take two palms, do all of that logic in the code but this is not what a text input is supposed to do, right, your app has a very custom logic nobody's app has the same thing nobody else needs this yet, so we shouldn't actually have it in the text input so we broke away from this pattern and said, you know what you would take care of your own label you guys want to do goofy things I'll give you a function, right, you just pass like a function which renders the label and I'll just call your function and you can do whatever you want and as long as it returns JSX, they're cool, right, if it's like JSX I can render in React I'm happy, so I'm going to pass you the length and you can like render the length as is or you can do fanciness with it, it's your call I'm just going to give you a length, give me JSX this is called a render prop the basic idea is that you're passing the control of rendering stuff to the user, right, not the component itself but to the user who uses the component, so you take a prop which is the render prop and you call it so that it returns your JSX which you insert which is supposed to be rendered, right, so this is like a super powerful pattern where you want to control state but you don't want to control presentation, right, you want to pass off the presentation to the user let's see how does this look this is the example of the render label we have this, we're going to have two class names, 25 is born 30 is error, they're going to attach class name to the span, I don't really care, do whatever you want in the render label how we take care of this is this so instead of our span the label that was putting the length we literally call that function, we say this prop's render label function and we pass length, we pass this.state.length and because inside of JSX we have component JSX you can actually call functions just wrapping them in curly braces you can actually call an external function an internal function accept it as a prop, it's pretty powerful so yeah, this is what we do, we say we're going to call your function, give us what you want you can actually take this to the next level as well, where you say we've created a text counter method, which only counts the amount of characters that you render now you decide what you want to render we just accept one prop which is render, which is a function and then we're going to give you back the length and then you decide if you want to make the input also red input yellow, go crazy if you want to make one give us JSX this is render prop and this is getting pretty popular this is kind of the new puppy instead of high order components it's pretty powerful, you can see it kind of lets you do a lot of things React Router is kind of using this already so if you use React Router 4 this is in your production code base already bunch of other people have started adopting it, it seems to make sense so now this is the best one first one, I'm fairly new to the company so I don't know everything that's going on he comes to me one day and says, sit I'm going to show you a new product I'm going to give you fun we're doing cool things and he shows me this this is like a parallel project so we're doing a different branding because it's going to be a side product of its own we might keep it in the company we might make a sister company and sell it they basically break it into two companies I'm like all of that sounds cool but this thing has blue buttons you don't have blue buttons you have black buttons you have this and not this the switch is not green, the switch is blue you don't have grey buttons you have white buttons but one has a little border and the color is different to be honest it's not that big a deal it's just a theming thing the colors have changed but it's still a theming problem so we went back to components of the hardness we're like what can we change we have this form I can accept a theme in every component the button component give it a theme the black product is called manage so you give me a theme manager and I'm going to render it black if you give me theme extend I'm going to use the blue just give me the which theme you want I can do it but then you have to do it for every component or at least every themeable component input box doesn't care but the switch cares, the button cares so you kind of have to know which to pass and where to pass this is obviously not it makes sense for me but this is not what I want people to have to do all the time it's kind of painful so the ideal solution in this case would be you go to your top most element like the app component and wrap it with a theme provider you wrap your entire application in a theme provider component and just put the theme name once and what this should do is pass this information to all of the components that are inside the app and then theme them accordingly so this is pretty cool for people who want to use you just have to do this once depending on the product you're working on you say theme is managed, theme is extend you forget about it, the system takes care of it let's see how this works so first of all let me just say this is the provider pattern provider pattern you might have seen this with react router, redux any theme in next style components all of them have a theme thing going on so this is how you kind of use redux is the most popular one this is how you use redux as well I think you have a store provider I'm sorry my redux is weak say you have a store provider which you wrap in the app and then wherever you need the store you can have it the fun part about this is it uses this thing called context so this is from the react docs in some cases you want to pass data through the component without having to pass the props down manually at every level this is exactly our use case you can do this directly in react with a powerful context API and I don't know half of you are already making face in a context so you shouldn't use context I want to bring pitch folks and I burn you to the ground they said don't use context I'm like yes, yes they said don't use context and believe it or not the docs actually define what context is and then they have a section called why not to use context I'm sorry what does that mean that's enough so we are going to address all of these points super far and justify the context is the solution here vast majority of applications do not need to use context none of our applications will only the central library so that none of the others have to use it cool if you aren't familiar with state management libraries I kind of am applications these might be the solution use redox if you can we can't really have a state management opinion in the component library because we are dealing with design we don't want to impose that everyone should use redox we just want to give you pretty buttons so we know what to bring if you aren't an experience react them before you don't use context this is called advanced react confidence talks I'm going to do this this is the best one they have really try to scare you if you want your application to be stable don't use context it is an experiment of api and it is likely to break in future half of the crowd is like this guy is crazy he doesn't know what he is doing the interesting part to notice is they don't say the feature is experimented they say the api is experimented so they are going to change how you can use the api of it but context as a feature is going to stick around you can actually go to react what you say the parent report of it they now have a proposals report Andrew Clark who works on fiber and all those things he is actually working on a new proposal for context where the api is completely different but the feature still remains so context is going to live the api is going to break so we will have to do some refactoring eventually cool we got this we understand we are aware of this if you still insist on using context despite this morning try to isolate your context when the api changes you only have to change it in one place thanks for the advice we are going to take by the way redox mobile style components all of them use context so all of your applications are already unspeakable and vulnerable to break in the future so like something not a lot to say this is a recorded session so in the theme provider quickly how does the theme provider work is first of all we define three providers it basically just renders the structure and everything that is inside it now to add context we add this we say get child context theme is this.probs.name the name you pass gets said as a theme we act as a little picky about the types here they want you to strictly type this type context so you also have to say child context type theme is a string is a prop type of string it establishes the context in your entire application to use the context what you do is only in the components where you actually need it you go there and you say button.context types is theme prop type of string so here you are declaring an explicit dependency saying button wants context types just the theme nothing else goes there only the theme one gets here it needs to match the type otherwise bad things happen and where you get in addition to props you get another parameter context in your app in your button and now you can use this context to style it because now you have the theme so you can do this for every component that needs it we don't have to go in all of our app switch button only the things that need this we can add them there is one thing that I did wrong here which is first let me demo it fake demo but it's demo so when you change the theme these two components the problem they said try to limit it only one things because then it breaks it should be easy to change so let's go back and instead of saying button.context types let's create a function which adds the context and this function I'm going to extract it and put it in the only in the theme provider file so that all of my context magic happens in month one file so in this thing components I request the component as a parameter and I say component context type of component is theme every component that I get I only need to do this so even if the context API changes our add context function doesn't have to change only this one file we kind of tweak it around to whatever the new API is so it's fairly easy probably take like a deal but we have this whole fancy feature so this is the provider and yeah now I'm going to like tick it because we followed your advice and they're pretty cool with the API changes to come so these were the seven component patterns I hope you learned something new today that you can use in your applications and Siddharth follow me on like the bird social network Instagram thank you