React components are modular, isolated slices of functionality that connect together to build user interfaces. This lesson discusses the relationships between components.
React component relationships#
A lot of beginners to React can get hung up on how to structure their components, asking questions like:
When should they be split into new components?
What should they do?
How should they interact?
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 of getting started when building your projects or thinking about building new components and areas of functionality within your app:
Plan everything out to the nth degree.
Get started and refine as you go.
In an ideal world, there would be a mid-point between the two extremes, but I generally lean towards the second approach and refine as I go. If you’re new to React or find it more helpful to plan more rigorously then 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 want to 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 (don’t 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 large components that become hard to manage and maintain, new eyes on the components will struggle to assimilate the information and figure out what does what, and they’re harder to debug and test.
A good place to start with splitting your larger components down is to look at your component as a whole and to ask yourself a few questions:
What does this larger component do?
What parts of the UI is it responsible for?
Are there any areas of distinct UI that could be used elsewhere or abstracted 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.
Take another look at the diagram we made back in that earlier module:
We looked at this entire component, the
WelcomeMessage 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 stand to be isolated, or a lot of repeated sections of near-identical code that could be abstracted into reusable parts.