‫So we're back in a section
‫about thinking in React,
‫which is all about state, data flow, and components.
‫We already talked about state management in detail,
‫and so now it's time to talk more about components.
‫Now, when it comes to components,
‫the important questions that we need to ask ourselves are,
‫how do we split up a UI into components,
‫and when should we actually create new components?
‫So let's try to answer these questions in this video.
‫And one way in which we can start answering those questions
‫is by looking at component size.
‫So we can classify every component based on its size,
‫which means that we can place every component
‫on this axis of component size.
‫On one side, we have really small components,
‫and on the other extreme, we have huge components.
‫At many times, none of these extremes are ideal.
‫So imagine that we wanted to build this simple card.
‫One way of doing it would be to create
‫just one huge component for the entire card.
‫However, that would create a whole set of problems.
‫First, there is way too much stuff
‫going on in this component,
‫so it has way too many responsibilities.
‫So components are just like JavaScript functions,
‫in the sense that if a function
‫does too many different things,
‫we should break it up into multiple functions.
‫And so the same applies to React components.
‫Now, another way in which it becomes apparent
‫that a component is too large
‫is when it needs to receive too many props
‫in order to work properly.
‫So for example, if we need like 10 or 15 props
‫to properly configure a certain component,
‫that component is probably way too big,
‫and should be split up.
‫So in general,
‫these two problems make it very hard to reuse the component,
‫which is one of the big advantages
‫of components in the first place.
‫Also, huge components generally contain a lot of code
‫that might be complex and intertwined,
‫which ultimately makes the whole component
‫hard to understand and to use.
‫Now, does this mean that we should do the opposite
‫and create many small components like this one?
‫Well, most of the time,
‫that would probably be a terrible idea as well.
‫If we would build a UI or an entire app in this way,
‫we would end up with hundreds
‫if not thousands of mini-components.
‫This, of course, would create a code base
‫that is super confusing to navigate and to understand,
‫and it would be way too abstracted.
‫And if you're not familiar with the term abstraction,
‫in programming, it basically means to create something new
‫in order to hide the implementation details of that thing.
‫For example, when we create a button component,
‫the user of that component might have no idea
‫how the button actually does what it does,
‫because the implementation details
‫are hidden behind this abstraction,
‫so behind this component.
‫So in a way,
‫each new component that we create is an abstraction.
‫Now, if both ends of the spectrum,
‫so both really small and huge components,
‫have these problems, then what should we do?
‫Well, most of the time,
‫the goal is to create components
‫that strike the right balance
‫between being too specific and too broad,
‫or in other words,
‫between being too small and being too big.
‫Now, these problems that we identified here,
‫like components having too many responsibilities
‫and being hard to reuse,
‫can help us understand
‫how we should actually split a UI into components.
‫So using the same example as before,
‫first we had this with just one huge component,
‫and then we had a lot of small components,
‫and both these ways of splitting up the UI
‫are far from ideal
‫for all the reasons that we have talked about.
‫So instead, what we want is something like this.
‫So here we have a more logical separation
‫of the content into different components,
‫and some of these components
‫are probably even gonna be reusable,
‫like the heart button or the SUPERHOST label.
‫Also, each of these components
‫has a well-defined responsibility,
‫like displaying the price or the rating,
‫and they're also not overly complex.
‫Okay, and so from this,
‫we can now derive a couple of criteria that we can use
‫to split a user interface into components.
‫First, when we decide which components
‫we need to implement a certain UI,
‫it's important that these components
‫create a logical separation of the content,
‫or even of the layout of a page.
‫We should also strive to make
‫some of these components reusable
‫and ensure that each component has a single,
‫well-defined responsibility.
‫Finally, there's one even more subjective criterion,
‫which is your personal coding style.
‫So some people work better with smaller components,
‫and some people just prefer larger components,
‫and therefore, you need to create components
‫in a way that works best for you
‫so that you can stay as productive as possible.
‫All right, but now let's actually dig a bit deeper
‫into all these different criteria.
‫So what I want to do in this slide
‫is to give you something like a framework
‫that will help you create new components
‫from bigger components.
‫So the idea is that, when you're creating a new component,
‫and you're in doubt about what the component should include,
‫just start with a relatively big component,
‫but not a huge component,
‫and then split that bigger component into smaller components
‫as it becomes necessary.
‫But naturally, you will now ask,
‫when does it actually become necessary
‫to split big components into multiple small ones?
‫Well, that's where the four criteria come into play again.
‫so logical separation of content, reusability,
‫the responsibilities and complexity of the component,
‫and your personal coding style.
‫Now, of course, if you already know that you need
‫a small and reusable component, such as a button,
‫you can just skip all this and simply create a component.
‫But otherwise, you can just start big,
‫and don't need to focus on reusability
‫and complexity at the very beginning.
‫At some point, however,
‫you do need to worry about these topics,
‫and so let's analyze them one by one,
‫starting with logical separation.
‫So if, after writing your big component,
‫you feel like the component contains some piece of code,
‫or of the layout, that don't really belong together,
‫then that means that it's probably a good idea
‫to create a new component.
‫Now, about reusability,
‫if it's possible to reuse a part of your big component,
‫and if you actually want or need to reuse that part,
‫then you should take that code
‫and extract it into a new component.
‫Another sign that you should probably extract
‫part of your component into a new one
‫is that your component is doing
‫way too many different things,
‫or that it's relying onto many props.
‫So if your big component
‫has too many pieces of state or effects,
‫or if the code is way too complex or too confusing,
‫it might be once again
‫time to create a new, smaller component.
‫And finally, as I said in the previous slide,
‫it's important that you feel productive
‫when working with your components.
‫So if you prefer smaller functions or components,
‫just split up big components into smaller ones.
‫But on the other hand, if you prefer big components,
‫that's also totally fine.
‫It's all up to you, because remember, in the end,
‫these are all just guidelines and best practices
‫that will become intuitive over time,
‫and by then, building your components
‫will become second nature to you.
‫But as you start out right now,
‫it's great to have guidelines like this to help you out.
‫And speaking of guidelines,
‫I actually have a few more general guidelines for you.
‫So first off, you need to be aware
‫that creating a new component creates a new abstraction.
‫And we talked about abstractions
‫a bit earlier in this lecture, right?
‫Now, abstractions have a cost,
‫because having more abstractions requires more mental energy
‫to think about different components
‫and to switch back and forth between components.
‫So try not to create new components
‫too early if you can avoid it.
‫Next, it's important that you name a component
‫according to what it does or what it displays.
‫And don't be afraid of using long component names.
‫That's completely normal in React development.
‫Now, what's even more important
‫is that you never, ever declare
‫a new component inside another component,
‫and we will learn the reason for that in the next section.
‫What you can do instead
‫when you have some related components
‫is to co-locate these related components
‫inside the same file.
‫Finally,
‫and going back to our initial topic of component size,
‫it's completely normal that an application
‫has components of many different sizes,
‫including some very small ones and some huge ones.
‫So even though we said in the beginning
‫that very small components have some problems,
‫of course, we always need some small components
‫like these in any application,
‫because they're highly reusable
‫and have very low complexity,
‫which is sometimes exactly what we need.
‫Most apps will also have a few huge components
‫that are not meant to be reused.
‫For example, we might have a huge page component
‫which contains the layout of the entire app or a page,
‫and that might very well be a fairly complex component
‫which is not meant to be reused.
‫So in situations like this, don't worry about reusability
‫or about needing to split this component up.
‫And speaking of reusability, as you can see from this,
‫we can say that, as a general rule,
‫the reusability range is pretty similar to the size range.
‫So generally speaking,
‫the smaller components are, the more reusable they will be.
‫And of course, as components get bigger,
‫they will become less reusable.
‫But again, that's no problem at all for some components.
‫So not all components are meant to be reusable.
‫But anyway, finally,
‫we have all these medium-sized components as well,
‫which all have different degrees of size,
‫reusability, responsibility, and complexity.
‫So in the end,
‫our application will have many different components
‫across the entire spectrum,
‫and that's completely normal and natural.
‫And now, let's go back to coding,
‫and break up a huge component into many small ones,
‫using all the concepts that we have just learned about.