DEV Community

React Components vs Spaghetti: 5 Signs Your UI Is Becoming Unmaintainable

Gavin Cettolo on March 24, 2026

Last week I opened a React component… and immediately closed it. Not because it was complex. But because it felt hostile. You know that feeling:...

Read full post

Kai Alder • Mar 25

The guard clause approach for conditional rendering is something I wish I'd adopted earlier. I spent way too long nesting ternaries in JSX before realizing how much cleaner early returns make things.

One thing I'd add — the "God Component" problem gets even worse when you're working with useEffect. I've inherited codebases where a single component had 4-5 effects all depending on different slices of state, and figuring out which effect fires when was basically impossible without console.log debugging.

What helped me was treating effects the same way you'd treat the component itself: if an effect is doing more than one thing, extract it into a custom hook with a clear name. useAutoSave() tells you way more than a 30-line useEffect block.

Curious — do you have a threshold for component line count? I've been loosely using ~150 lines as my "time to split" signal but wondering if others have different numbers.

Gavin Cettolo • Mar 26

Thanks so much for this @trinhcuong-ast, really thoughtful addition

That’s such a good callout on useEffect. Honestly, that’s where things tend to go off the rails fastest.

I really like your framing of treating effects the same way as components. If it’s doing more than one job, it probably is more than one concern. Extracting to something like useAutoSave() or useFetchUser() not only improves readability, it also makes the side effects testable and reusable, which is a huge win.

On the “which effect runs when” problem: I’ve seen that exact situation too, and it usually comes down to two issues:

Effects depending on too many pieces of state
Effects that implicitly depend on each other (timing coupling)

Splitting them into focused hooks tends to naturally fix both, because each hook ends up with a much tighter dependency surface.

Gavin Cettolo • Mar 26

On the line count question:
I think your ~150 lines is a very reasonable heuristic, but I’d treat it more as a smell indicator than a rule.

Personally, I look for a mix of signals:

Cognitive load > line count: If I can’t understand the component without scrolling up and down multiple times, it’s already too big, even if it’s only 80-100 lines.
Multiple responsibilities: If the component is doing 2-3 of these, it’s a split candidate:
- Data fetching
- State orchestration
- Rendering complex UI
- Handling side effects
- Business logic
“Scroll test”: If I need to scroll to see these things…it’s usually time to extract something:
- the full JSX and
- the state/effects that drive it
Reusable logic hiding inside: The moment you think: “I might need this logic elsewhere”, that’s your cue to pull out a hook or helper, not later.

A pattern that’s helped me: Instead of thinking “max lines”, I try to aim for:

Component = composition + layout
Hooks = behavior + side effects
Utils = pure logic

So ideally a component reads almost like:

function ProfilePage() {
  const { user, isLoading } = useUser();
  const { save } = useAutoSave(user);

  if (isLoading) return <Spinner />;

  return <ProfileView user={user} onSave={save} />;
}

If it starts drifting away from that shape, that’s usually my signal to refactor.

TL;DR
Your 150-line rule is solid, but the real threshold is:

“How hard is this to reason about in one pass?”

Once that breaks, it’s already time to split, regardless of the number.

Curious back: do you tend to extract UI subcomponents first or hooks first when things start getting messy?

Luca Ferri • Mar 24

Great topic, this hits very close to home.

The part about components slowly turning into “do-everything” monsters really resonated. I’ve seen this happen in almost every React codebase I’ve worked on: what starts as a clean, reusable abstraction ends up buried under edge cases, conditionals, and “just one more prop.”

One thing I especially liked is how you framed the warning signs, not just the solutions. A lot of articles jump straight to patterns, but recognizing the decay early is the real superpower—because once a component crosses that line, refactoring becomes painful and often avoided.

Also +1 on the implicit message: reusability isn’t the goal, clarity is. I’ve seen teams over-optimize for DRY and end up with components so abstract they’re harder to reason about than duplicated code.

Let me make you a question: Where do you personally draw the line between “this should be one flexible component” vs “split it into 2–3 simpler ones”?

Gavin Cettolo • Mar 24

Great question Luca, this is exactly where things usually go wrong.
For me, the line isn’t about size, it’s about cognitive load and intent.
If I need to mentally simulate multiple scenarios to understand what a component does, it’s already too flexible.

Here’s how I usually decide:

Keep it as one component when:
- It represents a single, clear responsibility
- Variations are minor (styling, small behavior tweaks)
- The API feels predictable (you don’t need a manual to use it)
Split it when:
- You start adding boolean flags like isX, hasY, variantZ that change behavior significantly
- There are multiple rendering branches that feel like different components glued together
- You need comments to explain when to use which props
- You’re afraid to change it because it might break 5 unrelated use cases

A simple rule I like:

If you’re adding a prop that fundamentally changes what the component is, not just how it looks, split it.

Another practical test:

If you can’t give the component a short, precise name, it’s probably doing too much.

In those cases, I prefer 2–3 explicit components with shared smaller primitives underneath, instead of one “smart” component trying to handle everything.

You lose a bit of DRY, but you gain readability, safer changes, and faster onboarding, which usually pays off quickly.

Luca Ferri • Mar 24 • Edited

Thanks Gavin for answering my question

Elen Chen • Apr 1

Great read, Gavin! 🚀

As someone who spends most of my time in the world of distributed systems and Rust, it’s fascinating how the same "spaghetti" patterns show up in UI code.

The point about "Conditional Rendering Hell" really resonated. In backend architecture, we try to avoid "God Objects" that do too much, and it’s clear that React components suffer the same fate when we start overloading them with boolean flags like isX, hasY, and variantZ.

I’ve found that once I start needing a manual (or a long scroll) to understand a component's rendering branches, I've already lost the battle against cognitive load. Your tip on the DataState wrapper is a brilliant way to restore that single entry point for behavior.

Quick question for you—when you start to feel that "entropy" creeping in, do you prefer to extract the business logic into custom hooks first, or do you focus on breaking down the UI subcomponents to simplify the render tree?

Gavin Cettolo • Apr 1

Thank you @elenchen!
Really appreciate the parallel with backend “God Objects”, that’s exactly the same smell.

For your question, I usually let the pain guide the first move.

If I’m struggling to understand what’s happening because of too many conditions, I extract a custom hook first. That helps collapse all those booleans into a single, explicit state and makes the component readable again.

If instead the issue is what I’m looking at because the JSX is huge or messy, I split subcomponents first to make the structure clearer.

In practice, both usually happen, but I tend to start with hooks because once the logic is clean, the UI decomposition becomes much more obvious.

So short answer: logic confusion → hooks first, visual complexity → components first

Elen Chen • Apr 1

Thank you @gavincettolo , I really appreciate your response and fully agree with your point.

Harsh • Mar 24

The bonus signs" section hit differently especially you've said let's not touch this more than once. That's honestly the most honest metric for unmaintainable code I've seen. No linter catches it, no PR review flags it, but every team feels it.

One more signal I'd add: when a new teammate asks "where does X get called from?" and nobody has a quick answer. At that point the component isn't just unmaintainable, it's invisible. The DataState wrapper pattern you showed is a great fix for exactly that it makes behavior findable.

Gavin Cettolo • Mar 24

Thank you @harsh2644 , that’s such a good addition.
“Invisible components” is exactly the right way to describe that feeling.

I’ve seen that moment a lot too: someone asks “where does this come from?” and the answer is either silence or a 5-minute archaeology session through the codebase. At that point, the problem isn’t just complexity, it’s lost navigability. And once you lose that, everything slows down.

What’s interesting is that this aligns with a broader pattern in UI decay: complexity doesn’t usually explode, it becomes implicit. Logic gets spread across hooks, effects, props, and conditionals until the behavior is no longer traceable in one place . Your “invisible” signal is basically the human version of detecting that.

I also really like how you connected it to the DataState wrapper. That pattern works not just because it cleans up rendering, but because it restores a single, obvious entry point for behavior. It answers the question “where does this happen?” without needing to think.

If I had to extend your idea: unmaintainable code is often not the most complex, it’s the code where you can’t build a mental map anymore.

And your signal catches that earlier than most “best practices” ever will.

Marina Eremina • Mar 24

Really liked the refactoring examples! I was just wondering, what if user or posts are underfined? Although, if Dashboard is only rendered after checking user, it should be fine 🙂

Gavin Cettolo • Mar 25 • Edited

Great question @marina_eremina and yes, that’s exactly the kind of edge case that can easily turn into spaghetti if not handled intentionally 🙂

In this specific example, you're right: if Dashboard is rendered only after validating user, then we're safe by design.

That said, in real-world apps I try not to rely only on parent guarantees. Data can be async, partial, or temporarily undefined (especially with API calls), so I usually add a small guard at the component level as well.

Something like:

if (!user) return null;

or even better, explicitly handling states:

if (!user) return <Loading />;
// or <EmptyState /> / <ErrorState />

React actually treats null as “render nothing”, which is a common and perfectly valid pattern for conditional rendering ()

So the rule of thumb I follow is:

Parent decides when to render
Component defends itself from incomplete data

That balance keeps things both safe and maintainable as the UI grows

Marina Eremina • Mar 26

I have to say this is one issue that I struggled with the most when working with React components: deciding at what stage the check should happen to determine whether the data is ready or not.

It’s great that you mentioned the rules of thumb, they basically reflect the conclusion I came to, and they can save someone a ton of time spent on trial and error while getting a sense of how to approach it.

Gavin Cettolo • Mar 24

I’m really curious!
Have you ever looked at one of your React components and thought: “how did this turn into such a mess? 😅”

vuleolabs • Apr 5

Nice article!
I've been building a SaaS landing page recently using Next.js and Tailwind.
It's interesting how modular components can make landing pages much easier to maintain.

Gavin Cettolo • Apr 7

Totally agree, that’s exactly where components really shine.

With landing pages especially, it’s easy to end up with a big “one-file hero + sections mess”, but breaking things into smaller, purpose-driven components (hero, features, testimonials, CTA, etc.) makes everything way easier to reason about and evolve.

I’ve found the biggest win isn’t just reuse, but isolation: each section owns its logic and styling, so changes don’t ripple unexpectedly across the page. That’s what really keeps things maintainable as the page grows

And with something like Next.js + Tailwind, that combo almost nudges you toward good composition patterns by default.

Out of curiosity: did you structure your landing as reusable sections from the start, or refactor into components later?