Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

When to Break Up a Component Into Multiple Components

DZone's Guide to

When to Break Up a Component Into Multiple Components

In this article, a seasoned developer discusses at what point does it make sense to break a single component into multiple components.

· Web Dev Zone ·
Free Resource

Start coding something amazing with our library of open source Cloud code patterns. Content provided by IBM.

Did you know that you could write any React application as a single React component? There's absolutely nothing technically stopping React from putting your entire application into one giant component. You'd have a HUGE render method, a TON of instance methods, a LOT of state, and you'd probably need every lifecycle hook (with the exception of shouldComponentUpdate (it should always update!) and componentWillUnmount (it will never unmount!)).

If you tried this, though, you'd face a few problems:

  1. Performance would probably suffer: Every state change results in a re-render of the entire application.
  2. Code sharing/reusability would be... not easy.
  3. State would be a challenge: Knowing which pieces of state and event handlers went with what parts of JSX would make your head hurt and lead to some hard to track down bugs (this is one benefit of the separation of concerns).
  4. Testing would be 100% integration: Not necessarily an altogether bad thing, but it would be pretty tough to test edge cases and keep things isolated to the parts that you're trying to test, so maintaining those tests would be a challenge.
  5. Working together on the codebase with multiple engineers would just be terrible. Can you imagine the git diffs and merge conflicts?!
  6. Using third-party component libraries would be... ummm... impossible? If we're writing everything as a single component, third-party libraries are at odds with that goal! And even if we allowed the use of third-party components, what about HOCs like react-emotion? Not allowed!
  7. Encapsulating imperative abstractions/APIs in a more declarative component API wouldn't be allowed either, meaning that the imperative API would be littered throughout the lifecycle hooks of our one giant component, leading to harder to follow code.

These are the reasons that we write custom components. It allows us to solve these problems.

I've had a question on my AMA for a while: Best ways/patterns to split an app into components. And this is my answer: "When you experience one of the problems above, that's when you break your component into multiple, smaller components. NOT BEFORE." Breaking a single component into multiple components is what's called "abstraction." Abstraction is awesome, but every abstraction comes with a cost, and you have to be aware of that cost and the benefits before you take the plunge

"Duplication is far cheaper than the wrong abstraction."  -  Sandi Metz

So I don't mind if my component's render method gets really long. Remember that JSX is just a bunch of JavaScript expressions using the declarative APIs given by components. Not a whole lot can go wrong with code like that and it's much easier to keep that render method as it is than breaking out things into a bunch of smaller components and start Prop Drilling everywhere.

Conclusion

So feel free to break up your components into smaller ones, but don't be afraid of a growing component until you start experiencing real problems. It's WAY easier to maintain it until it needs to be broken up than maintain a pre-mature abstraction. Good luck!

Code something amazing with the IBM library of open source blockchain patterns. Content provided by IBM.

Topics:
web dev ,components ,react.js ,web application development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}