The React Cookbook: Advanced Recipes to Level Up Your Next App

hi everybody how are you all doing okay cool so I just want to start let me just open this up here for a second can you hear me okay by the way okay cool so I already got a sweet intro there thank you very much but just really quickly about me that's an actual photo of me those aren't yes those are my real biceps my real tattoos 100% I'm a web application developer I work at a software consulting agency and twg and I see a couple TW tears here hi I also teach at hacker u which is a toronto-based coding bootcamp as well as at Canada learning code and Emma mentor MTA with the bridge school and I'm gonna be like tweeting I already actually messed up my timing on this I already live tweeted the slides for this talk so if you want to cheat and get ahead or later if you want to see the slides just follow me on Twitter I posted them there so I wanted to start by this this talk is called the react cookbook and I wanted to start just with a show of hands how many people here cook without following a recipe how many people here cook without following recipe so I'm very very impressed because personally I have to say that like that is not an ability I have but I'm sure that y'all when you go to the grocery store you don't even bring an ingredient list with you you like squeeze produce and like smell it just to like no that's freshness or pluck it's leaves or whatever and you go home you cut up all your ingredients you know what you want to make you you go home and you end up with something that looks like this and I'm very envious of you I think that's very very impressive I on the other hand don't have this ability I need to follow a recipe in fact here's Halloween's coming up I was doing a little bit of October cooking here's a live look of me doing a bit of cooking so definitely not a strength that I have personally and this is the output of what I produce I think you should give me marks for presentation personally you know I it's a bit of a Halfmoon arrangement there but yeah like I typically need to follow a recipe and I find that when I follow a recipe I do end up with delicious tasting food and what I wanted to share with you is that I also find that when I follow code recipes I end up with delicious tasting react apps now you might be like a co and see what I did there and you might be thinking like a code recipe well what is a code recipe well we actually have a name for this in development this is what's called a design pattern a design pattern and what is a design pattern the definition of a design pattern according to I believe Wikipedia is a academic source is a solution to a recurring problem a zine pattern is a solution to a recurring problem so for example we have some kind of recurring software problem we follow a design pattern and we end up with some kind of delicious desirable code based outcome so what I want you to do is I want you to think about design patterns as the kind of recipes that help us cook delicious react apps and the goal of this talk it's called the react cookbook the goal of this talk is to add some recipes to your cookbook so we're gonna be adding a few different recipes to your cookbook so that the next time that you work on a react app or even the current react app that you're working on you can kind of cook with these recipes and end up with a presentation that looks better than that brie half-circle so we're gonna be learning these recipes and I just want to say that these are not recipes that I created I didn't invent them they're recipes that I have kind of gathered and collected from my time building react apps and specifically these are recipes that I would attribute to what I call the react top chefs so here we have chef Dan Abramov and we're gonna be looking at a few different chefs and will point out the chef as we get to them and talk about the specific pattern that either they created or they championed something like that so for our cookbook today the recipes that we're going to be learning about we're gonna learn about three recipes we're going to learn about the context API we're gonna learn about a pattern called presentation and container components and then we're gonna learn about render props if any of you attended the West boss workshop I believe he actually covered some of these as well so I'm glad we're not like on the same day in the same slot so we're gonna start by doing some cooking and we're going to start with first recipe now our first recipe that we're going to talk about is the context API this is a recipe that was championed by I first heard about it by Kent C Dodds it's also been a part of react for a very very very long time however a new version of it came out quite recently and when it did Kent Dawes who has a newsletter where he talks about just different react patterns things that he's excited about libraries that he's working on he kind of reintroduced the idea of using the context API so I think this is a statement that you can all kind of agree with I think when people first encounter react and the idea of passing props inside of a react app it can be very very frustrating now if you're passing props like let's say one level down here we have an app component that's passing some props to a menu component that's not that big of a deal but what happens if you have for example a sign out component and you want your dashboard to pass a prop into it well if it is rendered by an intermediary component in this case the sidebar component we have to pass it through side bar in order to get it into sign out and we have to do this even if the side bar component doesn't even use that prop at all so we end up passing this prop down our tree through a component that doesn't even need it and that's like not the best but then you can end up in a situation like this where you have to pass it through a side bar through settings into a reset password component so we're passing this prop down multiple layers inside of our app this is problematic because we end up passing this prop through a bunch of intermediary components that don't eat it it's also possible that through this journey during this time as it moves between all of these props sometimes it changes names for some reason the developer decides it's gonna be called something else and so later when you come back and you try and find the origin of this prop you have like four or five files open as you're trying to track it all the way back up the chain there's actually a name for this and again Kent Dodds was the first person I heard use this before but he refers to this as prop drilling or prop threading is another name that I've heard for this mmm and prop drilling is really really frustrating and I think especially when people are new to react it's something that they experienced quite early on in their journey if you were to ask like someone at your work I'm having this issue with prop drilling I keep passing this prop down the chain and I want to know is there an easier way to kind of resolve this issue they might say something to you like oh you should use redox so then you go okay I've heard of redox maybe you've used it before I'm just gonna go check the documentation and see what it says so you end up looking at like a diagram that looks like that and you're sort of like why is this so hard like all I wanted to do is just like pass a prop down without having to pass it through the intermediary components so why do I now have to add the boilerplate how would I have to manage the overhead of redox and the truth is is it's hard because like sometimes we want our state to be global but react the kind of unidirectional data flow of react the whole model that data moves from the top down react doesn't really want us to have or access global State in this way there's no real way immediately visible to you to access parent state from a deeply nested component until now actually it's always been there but it's become more popular recently but yes until now so this is an introduction to the first recipe we're going to be talking about today this recipe is called the context API this definition comes from the react Docs which are great and it just says a way to pay past data through the component tree without having to pass props down manually at every single level so literally what we just described this gives us the ability to access a prop from lower down our tree without needing to pass it through the intermediary components so if we look at this diagram here this was a situation we had before we had a profile component that had to pass a prop from sidebar and settings so that it could be accessed by reset pass right here well with the context API we'll be able to do this instead so we'll have our parent component here profile it's going to have the data that we want to have accessed by the reset password so how does the context API actually accomplish that this it accomplishes it using two two kind of key components the first one is called the provider and you can think of the provider as a kind of global state container just picture it kind of like a big object in the sky essentially so it's some kind of object that we're gonna have access to you further down in our chain and the provider is going to be it's going to make this information available to us through another component which is called the consumer so the consumer has access to the provider we'll see that anywhere we render the consumer the consumer in our component tree will have access to any data that is stored inside of the provider without needing to pass that data down the tree so setting it up is actually really really straightforward and if any of you have experience with redux I think you'll appreciate the simplicity of this in comparison so the first thing that you do is you call a method that's actually just built in to react you call react create context and here we're destructuring to components off of the create the return value of create context we're restructuring a provider component and a consumer component and then what we're going to do is at the top of our state tree we're going to wrap our entire app inside of this provider component or at least we're going to wrap the part of our app that we want to have access to this information elsewhere in the provider component we're gonna pass a prop of value this is a prop that is like predefined and whatever we pass into value that's going to be accessible by the consumer and the consumer is going to be rendered somewhere else in our tree below so it just needs to be rendered in a component that is a child of the provider so for example let's imagine we have an app component that's storing a little bit of user data in its state here we have like a user name of guy fieri excellent cook and what we're gonna do is we're gonna take this user data you can imagine this came from an API or something like that we're not going to worry about that part of it it's not relevant for this but we're gonna take that data and we're gonna pass it into the provider component through this value prop here so you can see that we're passing the entire state tree here we're passing this state into the provider and within the provider you can see that we render a dashboard component now the dashboard component doesn't receive any props we're not passing this data user into it or anything like that and then as we move further down our tree we can see that our dashboard may be the dashboard renders the side by and the site again the sidebar doesn't take any props in it at all and then in the sidebar component when we render it you see that here we're actually also rendering our consumer component and inside of our consumer component you see that we have this function here that which receives a parameter of value and if we actually grab value user name will be able to print out guy fieri so we'll be able to access this state value from the top of our tree without needing to pass it down through intermediary components as props so just to visualize what this looks like we have our app component that has a provider inside of it and then further down our tree we have this consumer component which is accessing data from the provider without it needing to move in between dash bar and sideboard you can also have consumers at multiple levels of your component tree so if that information needs to be accessed in multiple different areas of your app which oftentimes with user data for example it does maybe you need to know in a sign in/sign out whether the user is currently logged in whereas like somewhere else you need to know some other piece of information about their user authentication you can just render additional consumers there and each one of them will have access to that value from the app component so if you were to visualize that it would look a little bit like this we have two different consumers and both of them are accessing this data from the provider at different different branches of your state tree and you can even get like more complex than this if you want to so you can end up with something like this where you have kind of branching branching components in your app each one of them that's rendering a consumer that's subscribing to this provider up here so the huge benefits of this pattern over like passing the props down or anything else is essentially we're eliminating this issue of prop drilling of needing to pass this prop down multiple levels inside of our app and we're also eliminating the need for Redux at this juncture in our application this is I want to just a caveat with this like pattern this is not that you don't need redux you can only you can just use context API that's not what I'm saying what I'm saying is a lot of the common use cases that people initially use redux for which is to avoid this sort of prop drilling you can just start by using the context API so it gives you the benefit of deferring that decision to a later date down the road of your web applications like life and you'll see that that's also very important like as we go on being able to defer decisions until later so when do you use it when do you use the context API well you use it when you find yourself passing props like all the way down your tree so they can be accessed lower down if you find that you do have some global state that you need to know about everywhere in your app and you will find that when you build your web application there are certain things that you need all in all kinds of different places in your app like user settings for example and if somebody tells you that you need redux just like stop think for a minute and ask yourself if you can if what you're trying to do can be accomplished by the context API and if it can I would suggest starting there before trying to learn the overhead and boilerplate associated with redux so what can you cook with it with this recipe you can cook a bunch of stuff some examples would be like a shopping cart system so if you do some kind of global shopping cart management in your app context API is really good for keeping track of like whether or not the card is open or closed or what's in its inventory if you're doing internationalization so you're managing translations across your app and you need to know like what language is currently active and where you want to store your translation strings you can use it for that it's really helpful for modal's again because like in different parts of your application you need to know like how to be able to open a modal from anywhere or close it and then it's also really good for building like a general theme provider so if you want to have like specific styling that you want to manage and like many different levels inside of your application it's quite useful for that as well ok so that's the first recipe that we covered the context API I now want to introduce you to the second one and the second one is presentation or container components this is a comes from an article that I read in like I think it was like 2015 so it's like quite old but I still I actually maintain that this is probably one of the most important patterns in react one of the most important recipes in react and I actually think it's one of the most important ideas in web application architecture period so I really really recommend that like you not only think about this in the context of react but also just in terms of building web apps so I want you to imagine for a second that you were asked to build this weather widget component so we can see that this weather widget services some kind of information about the weather and then it also has this kind of visual component to it so we're rendering some kind of content onto the screen so if we were going to build this we need to kind of think about two different things we're gonna need to request some weather data from our our API that keeps information about our weather and then we're gonna display that data on the page so you're like okay cool I know how to do this it's like pretty straightforward I'm gonna build this component it's gonna be called weather widget and when the component mounts I'm gonna request the weather through get weather and then in the render method I'm going to just display that content I'm gonna display the information about the weather onto the screen this is fine you're like super stoked about your your component here it's like really small very portable etc but then what happens is over time you actually need to do more stuff here they want you to add like a 12 day forecast to it be able to show like Fahrenheit and Celsius all kinds of other things about the weather I don't really understand how the weather works but they want you to do all this other stuff and so you start to expand your component and it ends up looking a little bit like that and that is bonkers this is so big that I had to like zoom out and take two screenshots in order to get it to fit on the screen and this this component is suffering from what I would describe is like this is a bloated component this is a component that is too big and why is this problematic this is problematic for kind of three main reasons it's really difficult to reason about when I say reason about I mean it's really hard to look at it and understand like wTF is going on do you know what I'm saying like it's really hard to know what it's doing because there's so much code there it's really hard to modify and reuse so like you try and change it and it like breaks or you just can't really use it in multiple places because it's so specific to the one area where it's being used and it's also super unfriendly to other developers like it feels like you can't tuck no one can touch that component because if anybody touches that component it's just gonna explode into a million pieces so how do we avoid this how do we avoid this pattern of like these bloated components that are like untouchable and really scary so this is the pattern this so it was proposed by Dan Abramov in this 2015 article presentational and container components and the key idea of this article is an idea that's not exclusive to react but he's introducing the notion of separation of concerns separation of concerns is an incredibly powerful concept when it comes to web application architecture and just programming in general what do we mean by a concern a concern is literally just something your code is responsible for some thing your your code cares about and if we think about our weather widget component it kind of cares about two things it cares about fetching data and it also cares about displaying data so these are our two concerns and then the idea of fetching data this is a logic based concern it has to do with like managing state going and requesting data from the API and then displaying that data on the screen that's a UI concern it has to do with like a visual representation of something so what Dan Abramov proposes in this recipe is he proposes that we take these two kind of disparate but connected things and we actually separate them into two different components first we have our container component and our container component is going to be responsible for managing the logic of our weather widget and then we have our presentation component our presentation component is going to be responsible for the user interface it's gonna be responsible for what the user actually sees let's start by talking about the container component the container component is responsible for what our widget actually does in our case or other aka the logic so in our case the widget is responsible for getting data and storing that data in state and what Dan Abramov proposes is he proposes that we call this component whatever the thing is container so we have weather widget container in this case and if we look at like what this component actually looks like we have this component did mount here which requests the it requests the data and stores it in state and that's all the container is going to be responsible for it's just going to be responsible for requesting the data and storing it in state but what about the render like what is the actual UI for this look like well that's where we introduced the presentational component the presentational component is what the thing looks like and again Dan Abramov if the container is called like weather widget container we just lock the word container off here and we call the presentational component weather widget so now we have these two components this weather widget container per component and this weather widget component and what will happen is that the container will actually render this weather widget component it will render it and it will pass in any data that the weather widget needs to know about in our case it's going to pass in the state data that's keeping track of information about the weather and then the weather widget component our presentational component it looks like this so what it's doing is all it's responsible for all it's concerned with is receiving some props which have information about the weather in them and then rendering those onto the screen so there's a couple of things you'll notice really quickly right off the bat the first is that we can use a functional component here we don't need to use a class-based component and the reason that we can do that is because we're not there's no state being managed in this component and there's no lifecycle methods being managed in this component and what that means is that this is a much much much simpler component and therefore like a much easier to reason about component the only thing that this component is concerned with is displaying some content onto the screen based on some data that it received so why is this pattern useful this container component and presentational component pattern it's useful because it's it makes the code a lot more reasonable easy to read I mean sorry so if you go back and you think about if you think about that bloated component that we were looking at before we've taken that content and we split it into two different components and and that is going to make it a lot easier for us to also hunt down bugs basically what we can do is if we see that there's some kind of information some kind of issue with the data that's coming back from the API or something's not being set in state properly something that is kind of a logic based issue we know that we need to debug this inside of the container similarly if we look at the thing on the screen and as we look at it it looks as the kids say jacked it looks messed up then we know that that's a that's a presentational issue that's a visual issue and we can debug that inside the presentational so we're able to really isolate our potential technical issues with our components and debug them in a way that is like we'll just be able to debug faster and we'll have more confidence in our approach technically this pattern also makes the the presentational component the weather widget reusable in other places if we wanted it to I'm a little bit skeptical about this this is something a Dan Abramov says I'm a bit skeptical about it because it requires that presentational component to receive the identical props as it would from the current container but theoretically if you had another container elsewhere and passed data into this component you could theoretically use that presentational weather widget elsewhere and then the other thing that's really good about this pattern is that it's much more testable so for your presentational component if you're familiar with snapshot testing you would you could easily write a snapshot test for this and just mock the props that are being passed in then you have like total coverage on that component you're good to go and then for the container component that one you could unit test with more of a kind of logic based approach so the question is like when do when do I use it when do I know to use this particular recipe this presentational and container component recipe well you some of the like early signs essentially if you look at your component and you're like damn this is doing too many things that's probably a good sign that you can split it out in some way and this approach of separation of concerns is a good way to start if you look at it and you're like oh this component is responsible both for determining what something looks like as well as like what it does or like some kind of logic based work you probably want to split these into two components also literally you could just count the number of lines if it has like thousands and thousands of lines inside of it it's the component is too big and it needs to be split out into these kind of separate concerns these separate components so this pattern the pattern of presentational and container components is incredibly powerful it's something that you can use in small apps and in massive apps so it's a very very scalable pattern and they will immediately make your codebase more manageable so I really really recommend that like when you're working on your react apps whether it's like your next one in your current one or if you're building a view app or whatever just ask yourself like do I have good separation of concerns in my application have I separated my presentation layer from my logic layer and I think start introducing this pattern into your app and you'll find immediately your app is like more pleasurable for you to work with and also for other developers to work with as well okay that's our second recipe so that was the presentational container components we talked about context API and now I'm gonna talk about our third one our third pattern that we're gonna talk about our third recipe is called render props and render props have been popularized by a lot of different developers it's actually now part of the react documentation so like you'll see them in there as well but I kind of first heard about it through a talk by chef Michael Jackson and he's an incredible incredibly smart developer who has a lot of really awesome ideas and he gave this talk about the value of render props and to explain like why you would use render props in the app I'm gonna kind of imagine a hypothetical scenario where we're building a puppy voting app so we're gonna build an app here that's essentially for voting on adorable puppies so like people see a photo of a puppy and they can either say that it's like adorable or like incredibly adorable that's like basically the scale so you're like okay cool I'm gonna start building this app and I first thing I need to do is I need to build this puppy feed component cuz I need to go get some puppies it's not for feeding puppies it's like a feed of puppies I need to go get them from the API so you're like cool I'm gonna build this puppy feed component this this whole example by the way was just like an excuse to like Google a bunch of images of cute animals so the first thing that you're gonna do is you're like okay I need to make an API request to slash API slash puppies while we're waiting for this puppy data to come back because there's a lot of adorable puppies we'll service a loading spinner and then when the puppies come home we're gonna render them onto the screen and if there's an error like we're unsuccessful in retrieving the puppies which would be so sad then we will render the error on the screen so you build this and you're like dope this looks incredible super excited it's testing while in the focus groups and your manager she comes to you and she says this is great can you also can we do the same thing but we do it with kittens like let's do it like a kitten feet as well and so you're like okay cool yeah no problem we'll follow a similar pattern here what we're gonna do get slash API slash kittens we're gonna surface a loading spinner and we're gonna render some adorable kittens if there is an error we will render the error and you kind of look at this and you go interesting interesting very interesting in fact like we're kind of doing the same thing twice right we're requesting this thing servicing a loading spinner rendering adorable creatures and then if there's an error rendering an error and you go the only real difference between these two is like one renders puppies and the other one renders kittens so you're like okay you put your dry hat on or do not repeat yourself hat you go there's this is an abstraction opportunity you get very excited and you say let's create a pet feed and the way that this pet feed is gonna work is that you're gonna pass it a pet as a prop so you say like pet feed pet is equal to kittens and that will get you kittens and pet feed pet is equal to puppies and that will get you puppies and you're like don't crush tit now that I've got this amazing abstraction here it works for kittens and puppies later if we wanted to have adorable Turtles we could probably use it for that too there's like a high high level of potential with this the next feature that that your lead she comes to you and she says okay this is awesome we're doing really well and now what we want to do is we want to have like a user profile and the user profile is oh the user profile is it's going to do a couple of things that's going to get information about the user and surface that data into the screen so you go okay cool it we're gonna do get slash API slash profile we're gonna surface a loading spinner you get the idea it's very very similar pattern and then you go oh it's just interesting this is kind of like the pet feed it actually does the exact same things as the pet feed except it renders a user's profile and then you think like but the presentation of this is going to be different we're not gonna have a gallery of adorable pets maybe we're gonna have some like inputs here where you can like type in like change the password or something like that so you're like how do I like kind of like blend these things how do I use my pet feed component here do I need to abstract that or I need to use like duplicate logic here in order to like make this work for the settings page and while you're kind of like thinking about the best way to do this your manager comes to you and is like oh I had this awesome idea we want to do this depending on if it's loading puppies or if it's loading kittens we want to actually have like a different spinner so like if it's puppies you wanna have this like little dog prancing around and if it's kittens we want this like weird mystic upside down floating kitten and so you think like oh well actually they're like the same component and like I don't know maybe I need to add like a conditional statement in the component if it pet is equal to puppy then show that or a kitten and you sort of start realizing that your pet feed component is like on the cusp of becoming like spaghetti essentially at this point it's it's it's an abstraction that's not working for you and we can't use it for the user settings page either so what happened like we had such good intentions with our abstraction so why did this happen well the reason this happened is because tight coupling of our logic and presentation made our component less reusable and flexible so because we connected our logic and our presentation to each other we kind of got backed into a corner prematurely so the solution to this is a pattern called render props and render props there's a lot of like confusing language around render props this is actually the definition of render prop a render prop is a simple technique for sharing code between react components like really at a core fundamental level that's what a render prop is used for it's just used for you have some logic you have a bunch of components that want to use that logic so let's use this render prop pattern this render prop recipe in order to share it and it looks like this the reason it's called a render prop by the way is because the name of the prop typically it doesn't have to be called this but the name of the proper a typically that you use in order to like take advantage of the render prop a turn is called render which is kind of confusing because like that's also something that a component does it like renders something but I just want to point out that like if this prop was called pizza then this would be called the pizza prop pattern so this can kind of have whatever name that you want so we need to think about how we can actually use this render prop in our app for our three different scenario we have this user settings page this kid in kittens feed and this puppies feed and the way that we can kind of use this is we need to realize that like there are things that these components have in common they all request data from the API they all need loading States and they all have error states but actually the way that they render is quite different like they all render different things the pet and kitten feed render things related to adorable kittens the user component renders like settings and they also render different loading spinners now and potentially later could render different error states as well so we have all these different presentational concerns that we're not going to know about yet and again as I said before we want to try and defer the decision-making around like what they look like till the latest time possible so they have common logic and different presentation and the way that we're going to resolve this issue is by renaming our pet food component we're gonna call it a resource component instead and this is a pattern that I used recently in an app at work it was very very very successful approach I'd say this component ended up being used like I don't know maybe 50 times in different places in the app and like generally like my new thinking about react and like building apps is like if you write a component that a bunch of other developers are using in a bunch of different places and it's working for all of their use cases and it doesn't have like a million props that's something to be really excited about that's something that you kind of want to shoot for this awesome reusability so how do we use this render prop a turn it's actually very very straightforward this is the key though when you're doing a render prop approach what you need to do is in this resource component this research component that we're creating you'll see that in the render method we call this dot props dot render this stop props dot render and again remember we said that render could be called pizza in which case this would be this dot props pizza so don't get confused by the word render here it's not doing anything magical it's literally just a prop that is a function that you're calling and what you pass into this function you pass in the information from the state that you want to care about later in our case we want to care about our payload our payload is going to contain our puppies it'll contain our kittens it will contain our user settings it's just going to contain an API payload of data and we also want to know whether it's currently loading so we want to know whether that data has arrived or it's on the way if we were managing an error state here as well which we probably should be but just to keep the example small we would also keep error information here so if in our request the request failed we would store that information in the state here you go the way that we use this is like very straightforward so we have the r2 props here we have a path prop and you'll see that we're actually using that in our component did mount here we call you know Axios get and we pass this dart props up path that tells us what endpoint we want to hit and so what we say is a resource component want to access this path and we're gonna pass in our render prop here and our render prop is going to have this data payload and this data payload is literally just the state of the resource component so inside of there we're gonna have access to data dot loading and data dot payload and if we had an error and like we're handling errors here we'd have access to data dot error as well if we wanted to so we have access to all these props here and what that means is that we can actually defer the decision-making around how these components render to the specific place that we want them to render so here for example this is the component that we're using on our puppy feed page so we can actually handle all the presentation around showing a puppy in this view without needing to worry about making the request knowing if like the duplicating the logic around like whether it's loading or not any of those sorts of things so all we're concerned with is the actual presentation here and similarly we can do the exact same thing with kittens right so we can see that all we need to change here is our path we just changed our path and then we have access to the same properties we have access to the payload etc but this time it will have our kittens inside of it and even the user profile page which is like completely different than the other ones all that logic around requesting loading etc that can all be handled by our resource component and in here we can have like a completely different style of presentation we could have inputs etc and we're able to handle all of those things in this view without needing to worry about duplicating the logic around how they're actually how that information is required did also incidentally like the first pattern that we looked at the context API if you remember the way that the consumer worked is it had this value inside of it that uses a render prop as well so this is a pattern that's really permeating its way through the react ecosystem you've ever used react router react router has a render prop as well all of these kind of recipes are all kind of intermingled with each other so the idea here is we have the same logic but we have different presentation we were able to defer our presentation to a later time which means when we get our you know fourth request for some other kind of API type thing we need to do that's not the same as user profiles or the same as pets or kittens we'll still be able to use this resource component so this component is incredibly flexible and it's like looking towards the future for future uses that is a massive win especially when you start scaling a web application because when you like at twg we work in a very iterative way we're discovering requirements like you know on Monday and implementing them on Tuesday so the more components you have that will help you build things you didn't know you had to build yet the more valuable this will be in the long run so prop ready props I think are one of the most important patterns Michael Jackson also in another in that same talk argues that actually they completely replace the need for higher order components which is like a discussion for another time but it's an interesting idea they document incredibly well they kind of use the declarative style that we're used to with react so they kind of follow the the react spirit of doing things it makes it really easy when you look at a component at a glance to understand how it works they separate presentation from logic again because they allow you to defer that presentation to a later time and they also decrease code duplication because you only have to write our resource component once and we can use it anywhere they're super extendable so other people can build on top of them really easily they're incredibly reusable again like proof is in the pudding this resource component I built I got used way more times than any component I've ever written and they also abstract away logic which is important for a language that doesn't have the notion of privacy because privacy doesn't really exist in react I'm sorry in JavaScript there needs to be ways that you can signal to another developer that's looking at your code like hey here's the things that here's the public facing API here's the things you should be concerned about and then kind of abstract away the parts it's like you don't need to worry about this this is kind of internal stuff that is managed by the component itself when to use them don't ever start with a render prop this is like a just a general philosophy I would really encourage don't prematurely abstract anything wait until you have to use it like three times before you abstract it and the reason why I recommend that is because if you prematurely abstract anything you will get the abstraction wrong and the reason that you'll get the abstraction wrong is because you don't know the use case for it yet so wait until you need to use it three times and then hopefully usually at that point and another developer on your team will be like oh I noticed that you wrote the same thing three times this could probably be abstracted and you will be like you are correct share logic between components but not UI you kind of always want to do this that's a huge benefit other developers can what other developers if you want other developers to reuse your code which like these days is like the number one thing that gets me excited about programming is when I see other developers using components that I wrote it makes me so happy when you'd want to defer rendering UI to a later date when you were dealing with common States or events so for example if you need to manage I was working on a react native project where we needed to know whether the keyboard was open or closed and stuff like that it's really really useful for those kinds of common events as well okay so just some final thoughts all of these patterns have to do with managing state and I don't think that's a coincidence managing state I have heard it said I think was Kyle Simpson who said this that 90% of bugs come from improper state management or just like not having control of your state management so just remember that if you truly understand the state in your app that means that you will be able to have a fine-grained control over your app also some of these patterns are actually more verbose then like a more abstract and that's okay because the goal is never to actually write dry code the goal is to write code that is easy for other people to understand that's like the ultimate goal don't worry about it being too verbose if it's so terse it's like one line and nobody can read it it's useless it will never get used again cool so this is our cookbook this is your new cookbook that we kind of like worked on together here we had our Kent C Dodds homemade delicious lock-on text API presentation container component ah ah Abramov and chef Jackson's render props suit I forgot the X on graph souffl that's supposed to be souffle also I think there's supposed to be an accent anyway my French teacher would be so disappointed in me right now so these are the three recipes that we learned about today I just want to say really quickly that recipes are important for a couple reasons they're battle-tested which means that chefs have gone into the lab with the sommelier z' they've had done tastings got feedback read Yelp reviews etc they have a really good understanding of what is going to use be useful in them in the most use cases they're super easy to share because they're agnostic of code bases they're just patterns you can use in any code base they're really fun to use they're kind of like a choose-your-own-adventure that only has like a good path which again like none of you cook with a recipe so maybe you don't want that but there I find them really pleasurable because when I use them I have confidence that they're actually going to work really well and they're also familiar so if I see another chef cooking or ooh I can say to her hey I know that recipe here if you need to do something else I can kind of take over for a little bit we can trade off so they give you that kind of familiarity among a team that's really really useful and the last thing I want to say is recipes are just the starting point you don't need to exclusively follow recipes they're just a place to start to start to teach you about some of the important patterns in your ecosystem once you feel like you have a good understanding of these approaches that's when it's time and they're like in your cookbook that's when it's time to start writing your own recipes so that's when you go out and you start building on these recipes and you start sharing those with the community and you start building your own cookbooks thank you [Applause]

Channel: Coding Tech

Views: 117,128

Rating: 4.9193506 out of 5

Keywords: react, react.js, reactjs, javascript, app development

Id: lG6Z0FQj_SI

Length: 41min 46sec (2506 seconds)

Published: Fri Feb 22 2019

Reddit Comments

[u/swyx]

if someone would like to take notes/summarize please be my guest!

[u/tomius]

I found that using context is not the best when you have different variables that different components can share.

With hooks, it looks better, but using Rxjs and a sharedState hook was the best experience I've had.

[u/TravnikovRN]

Yea kind a good suggestions but for small projects.

IMHO in scaliable projects is better to normilize your redux data https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape and then pass it directly to components.

[u/NewDimension]

Great talk!

[u/fehrn_prelt]

Nice 👍