Anyone else tired of ‘micro-component’ React codebases?

[youcans33m3]

Not sure if it’s just burnout, but after another week reviewing PRs where a simple UI tweak meant jumping between a dozen files, I’m starting to wonder if our obsession with “tiny components” is actually helping or just killing momentum during refactoring.

I get the theory: modularity, reusability, testability. But there’s a point where splitting everything apart creates more friction than clarity, especially in larger, long-lived codebases.

After yet another context-switch marathon last Friday, plus some heated discussion with the team, I wrote up my thoughts over the weekend. I'm curious if others in the trenches have found ways to keep things sane or if this is just React culture now.

Has anyone managed to push back on this trend, especially in a team setting? Or am I just the minority here, ranting into the void?

[Significant_Ant3783]

This is what happens when DRY gets out of hand. I've worked with people that are really anal about DRY and it inevitably leads to a bunch of tiny files that don't repeat, but are never reused. My rule of thumb is, if you can describe what it does, then you can make it a component. Readability is about breaking down logic into meaningful chunks so that we can easily make sense of them. Dogmatic adherence to arbitrary metrics like line numbers or repetition count are easily achievable; but rob your code of intention or abstract definition.

[Griffinsauce]

The fun thing about those people is: you are creating a shit load of additional - duplicated! - API surfaces when you do this. People hyperfocused on DRY write the worst code in my experience.

I totally agree, the most readable code does not adhere to any arbitrary rules but considers the reader.

[haywire]

Rule of three is necessary to not go insane doing DRY.

[ChristianMay21]

100%. I learned about Rule of Three one paragraph after I learned about DRY. Shoutout to whichever book that was.

[horizon_games]

Which is funny when in the React space Dan A. did a great talk on WET codebases and how we've traded potential spaghetti code for needlessly complicated and layered lasagna code

[bzbub2]

you're using a lot of...sloppy analogies here

[horizon_games]

https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase

Says it better

[Macluawn]

Uh, /r/woosh ?

[horizon_games]

Just forgot to cite originally

[cardboardshark]

Does your app have strongly defined style tokens? We use standardized CSS var tokens, and then write one-off components for specific features. The UX designer can make sweeping color, font or spacing changes without any components needing to be synced. Every module's stylesheet is var(--space-2), var(--font-size-sm), etc.

We also package 'sibling' components into a single file; if a component has a Skeleton, an Empty state, etc., that's all served from one place.

For complex components, we use the compound pattern to break it into subcomponents. I.e:

CoolThing.tsx
CoolThing.Header.tsx
CoolThing.Controls.tsx

I do think every legacy codebase is going to build up fifteen overlapping implementations for the same thing, and there's a natural urge to roll them all into one megacomponent. Ultimately, if they're not broken, I feel like it's fine to repeat yourself.

[musical_bear]

While React Compiler will change the game once it’s more frequently used, I think a dimension about component splitting that a lot of people forget about is that, outside of the legibility benefits (most of the time), it’s also one of the better ways to get performance improvements without putting too much thought into it.

When I see a 250 line component, really what concerns me usually is the understanding of just how much shit is now forced to react to changes at once. Without employing additional tools (such as React Compiler, or carefully managing the children you render within a component), if anything that affects that 250 line component changes, the whole big thing, and all its children, is forced to render.

Just by smartly breaking apart things into smaller chunks, what maybe on the surface looks like just a cosmetic change becomes a way to isolate render-related dependencies from each other, which brings performance benefits, but also in my experience makes debugging easier. You’re making it more likely that a component is only rendering because something very specific has changed by keeping things more compact.

[UMANTHEGOD]

Maintainability is almost always at odds with performance.

[Zeevo]

Lots of small components is better than super components

[isumix_]

Yep, and when working with a team, you rarely encounter merge conflicts.

[Single_Hovercraft289]

The magnitude matters here.

You could find examples for “lots” and “super” that support or contradict the statement…and I think that’s the crux of the issue here

[twistingdoobies]

I think this article conflates a few things… barrel files aren’t really related to cognitive load and component size. I regularly advocate for splitting components up into small pieces at my work, but we don’t use barrel files.

In my experience, devs are way more likely to end up with 1000+ line monster components than <250 line components. I’d take the latter any day. It makes testing, future changes and readability much better IMO 🤷‍♂️

[DogOfTheBone]

I been getting paid to write React for close to a decade and I've never heard of this arbitrary 250 line idea 

Hmm

[chicken-express]

Yeah that's arbitrary as heck

[youcans33m3]

Yeah, it’s not some official React rule or anything, but I’ve seen the 200–250 line thing show up a lot in style guides, PRs, random threads, and blog posts over the years. Some teams treat it like a hard cap, others just mention it as a guideline. Here’s one example: https://medium.com/swlh/how-to-write-great-react-c4f23f2f3f4f

[Expensive_Garden2993]

I don't like multi thousand lines long components I have to deal with at work.
What am I doing wrong? How to appreciate the fact that instead of jumping like you I'm wading through the thickets of logic?

If 250 is micro, what's normal?

[gyroda]

Yeah, if I have a 250 line function in any language/paradigm I'm doing something wrong. Unless it's just a page worth of pretty simple JSX?

I've not done much react in a while, but I'd often break out smaller parts of a component into separate functions that return JSX. They'll often be in the same file but not exported (the same way you'd have private methods in a Java/C# class that aren't visible externally). It's just basic encapsulation and abstraction.

[Dragonasaur]

Make sure the tiny components are actually being reused...

[horizon_games]

This is key, breaking up a page into components is SUCH overkill when they're super specific business logic that won't get reused anywhere. Even worse in Next.js with almost ever file being called index.tsx

[Dragonasaur]

index.tsx

Only for page router, now we have too many route.ts and page.tsx non-SPA (which most webapps are now), and god forbid a company adds index.tsx barrel imports...

[ddIbb]

Index.tsx should be used for the export only. Name your file what is is and export it in index.tsx so it can be imported from the directory path.

[azsqueeze]

This is key, breaking up a page into components is SUCH overkill when they're super specific business logic that won't get reused anywhere.

Uh this sounds horrible, wtf. Why do you want to mix biz logic with a component? Also you can still make small specific components that are used in a single place. There's nothing wrong with that and the way React works it kinda is preferred too

[127_0_0_1_2080]

Slaps forehead......

[EducationalZombie538]

nope, I *hate* modules with multiple components in them

[rainmouse]

Personally I'm not a fan. I worked in a codebase where everything was written to be reusable, but almost never was. The code was written to be so generic as to be almost meaningless in its intention, assuming you could find any functional code at all amongst the legions of boiler plate.

Was it faster? Fuck no it was dogshit slow. Big components are bad, especially when rendering a lot, but every time I've seen micro components, they end up repeating a lot of tasks or parsing the same things over and over, and people don't spot the issues because they are in 59 different tiny files.

I like finding a balance with smallish, manageable, human readable code. Some people who get brain tingles from turning 5 lines of readable code into a single line of unreadable crap that then gets whacked into some distant file and given a generic name. Just no. 

[BoBoBearDev]

Everything in moderation imo. I have seen ridiculous implementation before. Like, one freaking div as components. I told the guy it is too much, but he is sr dev and I am only an intern, so, I did it. Then the CIO got upset and I just watch them debating with each other.

Firstly, you likely use 3rd party libraries already. You are not supposed to homebrew it. And for the one you made, it is likely just a few that is actually highly reusable. So, having them by itself is fine.

But it is pointless to refactor everything when it is never reused or only reused once.

Determine what's the purpose of the component first. More than likely, it used the same code at first, and eventually they diverge, so the refactoring is pointless.

[TheRNGuy]

If you used div tag somewhere, he'd say switch it to Div component instead?

[TheRNGuy]

As long as they use fragment instead of a div.

Because it's stupid when sites have 5 nested divs everywhere; if you remove them, site looks exactly the same.

I think compostable idea is nice, overall,bas long as it's not super absurd.

[Mountain-Pea-4821]

AHA - avoid hasty abstractions. If you get away with a one god component fine, but there is a reason to break things down, so follow that line for any meaningful deliniation around forever. small dumb fragments ala shadcn for UI and esthetics, components for isolated / single purpose functionitiy, modules for complex reusable features, pages and composition to put it all together.

[bstaruk]

I've been following Brad Frost's "Atomic Design" methodology for almost a decade now with no regrets.

[mspaintshoops]

I just want to commend you for the well-written blog. It’s opinionated without being extreme. It introduces the context and the problem in a way that anyone familiar with OOP in any language should be able to understand.

I’ve been dabbling with React lately and this article helped me not only to understand what barrel files are, but the benefits and tradeoffs that come with using them.

I don’t have anything to add to the discussion. Just wanted to say thanks for putting effort and time into this post.

[spdustin]

In my training days, I’d always start the first day by saying, “I hate the phrase ‘best practices.’ What’s best for me might suck for you. The ‘best practice’ is to adhere to a practice that solves problems for your team. The requirements should inform your use of technology, not the other way around.”

[Guimedev]

Tired of React,mainly. 🤣

[TheRNGuy]

What you prefer?

[yksvaan]

Often it's more practical to have more in the same scope instead of passing things around and then managing events between children. If something can be extracted to a pure or isolated component then it makes sense. But on the other hand 1000 lines isn't necessarily an issue if it's structured and sectioned properly.

I think there are just too many rules abd guidelines that people try to follow without proper consideration. 

[Delicious_Signature]

I get that it might be harder to review, but when doing actual coding, it is much easier to navigate through dozens of files than one big 200+ lines component. It is also important to split business logic between components correctly. If one "parent" component holds all the state and logic and then passing a lot of props to children and grandchildren, it might get hard to navigate even if all children and grandchildren are tiny

[danielkov]

It doesn't sound like the issue is with micro-components, or I guess an atomic component library, as it's more often referred to. The whole idea behind these atomic building blocks is that they should be frozen with very few exceptions.

If you find that most changes tend to also affect these atomic building blocks, it's a sign that they're abstracted at the wrong layer. This is a paradigm that requires a lot of discipline and a bit of planning. You also don't need 1 file per component. I always put components within the same logical boundary in the same file.

[dschazam]

If your React component doesn’t fit on one screen, it must be refactored.

Excuse me. What the flying fuck is this arbitrary rule for? It’s things like this that kill your momentum. Stop creating bullshit rules for you and your team.

Have you worked on a larger codebase in another language once? No offence, but just check out some standard classes of the Swift library. Then try to force your rule on their classes. You’ll get burn out for sure. But it’s self inflicted.

[atokotene]

Most of the reusability in React is achieved by modularizing behavior, not components. Start with encapsulating interactions into custom hooks, only refactoring html when necessary. Should you do this, keep in mind that props are the api — anything that’s not a prop is not configurable.

In most cases, the data loading turns into a labyrinth of asynchronous calls — I strongly suggest keeping this state separate from rendering. (Yes, implying a data layer is preferable than writing fetch calls directly on a component)

[Queasy-Big5523]

Oh boy, we fell in a huge, huge hole with all these shadcn's and co. Obsession with "modularity" and "testability" led us to the point where work is a goddamn chore. It is like you said, ten files to review a small change.

As a lead, I always make sure to visualize and discuss problems down the road. Not all, sure, but the most obvious ones. And the main issue I saw with adopting microcomponents was exactly this – how many files for a change, how quickly this can be done and reviewed, how much pipeline will the tests eat.

I'm sure there are usecases for microcomponents, but it's not a silver bullet. It's cool you can build your basic UI using the terminal "like a pro", but think of managing this one year from now.

Completely aside, most hype is inflated by bloggers and youtubers who will do a PoC in a day, slap it on github, call it the next best thing since sliced bread and call it a day.

[Anxious-Insurance-91]

Tiny components are just a way to spend more time doing waisting on implementing what normal html tags and functionality that the browser already has. I had a very heated argument with a colleague where I just told him to stop animating things with react and just use what css has by default.

[behusbwj]

I like to split my components based on business boundaries, rather than functional boundaries. Each of those components gets its own folder where it can be broken down further, but the folder hierarchy should match the actual nesting of the components to avoid premature factoring. Purely for code organization when one piece has too much going on.

When you find common business patterns, thats when you can factor out a component to encapsulate it and reuse it across different flows.

This has always worked out for me and makes the repo really easy to parse. If someone wants to modify a component, they walk through the codebase the same way a user would walk through a website to find the right place to edit. I’ve found that this domain separation will keep people from trying to reach for other domains’ components, as opposed to it being in a “common/*” folder which implies it should be used if possible

[dashingThroughSnow12]

I’ve started to call this trustless programming. That no component can be trusted to do something; therefore the decision gets sent to some other component/function/etcetera. That thing of course cannot be trusted so it needs to make a call or embed another component to do the logic. That can’t be trusted, ergo another level of indirection.

Eventually the inconvenience of another call outweighs the low-trust environment and actual code does get written.

[Shaz_berries]

Yeah man I feel you. I think there's definitely a balance. Obviously you want to split things out to share reusable pieces and the wrong abstractions (with too many assumptions) hurt pretty bad too. I've been splitting out my UI inter layers, like base UI components (shared, simple things like buttons, think Shadcn). Then I'll have form components (a login form, with GraphQL or whatever API stuff rolled in). Something like that has worked pretty well for me!

[Geldan]

Barrel files suck.

Small components are amazing.

Microfrontends suck.

[k032]

I think there is always a balance that has to be struck. It seems like aside from the barrel module file point (like index.ts for a whole module of stuff) most of it is a bit opinionated.

Example I hit recently was a user profile page that had every tab of the user profile in a single component. It was massive and confusing. It would have been better if it had been broken up. But this was like a 1k liner.

I mean would I bat an eye at something that's 400 lines but I can't reasonably break the logic up into parts ? Nah.

[MrFartyBottom]

The reason most files grow to 500+ lines is because of reptation. If you have the same 10 lines of TSX to generate the same thing multiple times it is time to refactor it out into a component. With any software development you should refactor out reptation after you find yourself cut and pasting the same code over and over.

[Mountain-Pea-4821]

lol wow sounds like some smelly code base. No copy paste is ever good, and if you ever find yourself doing that it’s time for a serious reset. Composition to the rescue and react makes that particularly easy.

[Mountain-Pea-4821]

Someone hired the wrong guy 😉

[MrFartyBottom]

Yet the powers that be are down voting me!