When Should You Split Up React Components?

Lesson 2 - React Component Relationships A lot of beginners to react get hung up on how to structure their components asking questions like when should they be split in the new components, what should they do, how should they interact, and how can I pass data between related components. Hopefully in this lesson we can answer some of these questions and give you some guidance on good places to start when thinking about your components. Splitting up components There are two ways to get started when building your projects or thinking about building new components and areas of functionality within your app. 1 - Plan everything to the nth degree or 2 - Get started and refine as you go In an ideal world there would be a midpoint between the two extremes but I generally lean towards a second approach and refine as I go. If you are new to React I find it more helpful to plan more rigorously than you might find the first approach fits your needs better. My approach tends to involve getting something rough and ready working and then looking to refactor it as I go. I have an entire article on continuous refactoring on my website that helps with this idea too. The point here is that you want to have a good idea of the data and information that you want to consume and present to the user and manage their interaction with it. Then you will be able to break these areas of responsibility into smaller, more manageable chunks that are reusable across different parts of the app, keeping your components as dry or repeat yourself as you can. You can of course do this with fewer larger components that are like a Swiss Army knife doing multiple jobs at once. The drawback to this approach is that you end up with very large components to become hard to manage and maintain. New eyes on the components will struggle to assimilate the information and figure out what they do and they are just harder to debug and test. A good place to start with splitting our larger components down is to have a look at the component as a whole and ask yourself a few questions. What does this larger component do? What parts of the UI is it responsible for? And are there any areas of distinct UI that could be used elsewhere or abstract ed so that this is possible? Visualize the component split. We touched on some of this visualization right at the beginning of the course when we built our welcome app. Let's take a look at the diagram we made back in the earlier module. We looked at this entire component, the welcome message component and thought about how we could break this down into smaller, reusable elements. Although we decided that it's a little overkill for this specific component, this practice is very useful to do when you have larger blocks of code that could be standard to be isolated and a lot of repeated sections of near identical code that could also be abstracted into reusable parts. This way of drawing out the slices of a whole UI section will help you to visualize the possible components you can break down the complete UI down into as well as seeing at a glance their relationships with one another. So let's take a look at a component splitting example. Let's take a look at a typical piece of UI that you might find on a blog post, a comment. Now admittedly this isn't a huge component but you can see that we have a very fairly familiar pattern in our user info div. This slice of UI that renders a user's avatar image with their name might be used across our site in a number of places, a blog comment, a user profile section, my account area, in a list of popular commenters or in a recent visitors section. So straight away we can pull out this user info section that houses their profile picture in their name into its own reusable slice of the UI like this. Now back in our original post comment component we can replace this section with our new component. You could quite easily create components for the part that display the comment date and comment body content but this was only served to create unnecessary complexity and extra components. We don't add anything helpful by doing this because these sections in particular adjust a simple paragraph tag and an ordinary div element with a CSS class attached to it. Balancing re-use with project complexity. This brings us to a good talking point about exactly how much splitting down a UI into separate components is needed or a good idea. If you ask Facebook themselves they'll admit that they have tens of thousands of components however Facebook is a huge site much bigger than your likely ever to work on with thousands of distinct areas of UI that each have a common overlap in some parts, a bit like our avatar image example above. For average project sites and apps even really large ones I think it's important to strike a balance between reducing re-use by abstracting common functionality in UI and adding to project complexity. The user, which is ultimately who you're building your UI for, doesn't care or know or really need to know our care about how your project is pinned together. There's also a very little argument for any performance gains over having several large components over a ton of small ones beyond the glaring one that is more re-use equals less code on the front end bundles. Really the great gains for splitting down your components are several fold. You reduce code waste and repeated blocks of code or UI. You reduce large component complexity and responsibility. You shift that responsibility into smaller isolated blocks the individual components themselves. Your UI becomes more composable because you have a number of distinct building blocks. Unit testing becomes much easier. And troubleshooting and debugging becomes more forgiving as narrowing down the trouble spots is now easier. So then since we're largely doing it for ourselves as developers and the maintenance of the project, you could agree that it's key to be able to reduce redundant and overused blocks of code. But keep in mind that every single thing doesn't need to be a separate component. In our example above, it made sense to abstract the user avatar component. Sure, it's a small slice of the UI, merely an image element and a paragraph, but in this combination coupled with some styling information could be repeated across the site or app many times in many areas. If we needed to change the look and feel our functionality of the user's avatar , we now have a single, easily tested component that just needs changing in one place. It makes sense to abstract related pieces of UI information into distinct components even if they are small. But try not to go as far as to make every single thing into a component as you 'll end up with a bloated project full of components that becomes hard to navigate. [BLANK_AUDIO]