The naive logic that drags you to Hell

Components are great

Splitting large code blocks into modular components is a good practice for maintenance.

It keeps the code DRY, and allows you to reuse your own tools for similar purposes.

The problem is that it can quickly turn into technical debt.

Repeated props leave smells

It's not a question of beginners vs. pros.

It happens all the time.

You can even see it in some open-source templates.

The same props are passed through every intermediate component, even though many of them don't actually care about the data.

This bloats component APIs and can ultimately prevent you from implementing what you want.

You lose many benefits with this naive approach, such as:

• readability
  


• clarity of intent
  


• flexibility (any change in a child component requires modifications across the whole chain)

Why do we do that?

This naive implementation is probably the first one that comes to mind.

Okay, I need that data in that component

No big deal I'll pass it through this intermediary component.

The problem with components is that you'll likely create lots of them, so a small code smell can easily grow into a big problem.

How to overcome the challenge

Writing maintainable code is challenging!

There are recommended patterns, such as:

• Use stateless, pure components — components that only depend on their parameters.
  


• Keep it "atomic": as small as possible.
  


• Define strict boundaries: data should live where it belongs.
  


• Use structured objects instead of primitives: instead of multiplying parameters, use clean objects.
  


• Use shared context and services instead of intermediary components.

These simple guidelines can be very powerful, but there's no magic recipe.

You can safely apply them as long as they make sense for your use case.

Endless refactoring vs. realistic goals

You'll probably never find the ultimate architecture or strategy.

That's great, because you don't need to.

Evaluating your own work can be hard, but there are some good indicators:

• Components are reusable.
  


• Regressions and conflicts are rare.
  


• The number of modified files stays low in pull requests, making code review easier.