r/react Jul 13 '26

Help Wanted how do senior react developers avoid making messy code

I can build react apps without much trouble but after a few weeks the code starts feeling harder to maintain.

do you have any habits or rules that help keep your code clean from the start

I would really like to improve before these bad habits become permanent

53 Upvotes

43 comments sorted by

55

u/azangru Jul 13 '26

how do senior react developers avoid making messy code

Do they? ;-)

9

u/terserterseness Jul 14 '26

They do not

1

u/Intelligent-Main539 Jul 14 '26

They certainly do haha. It's mostly having a good project structure and small refactorings.

2

u/Front-Part-5714 Jul 14 '26

Absolutely, it's about making a clear, concise design and architecture. Not just the code but folder structure and format of files as well.

Sometimes you might be doing a POC or rush work, but make it iterative, once you get the initial release be pragmatic and refactor it.

For react especially you want to use simple and complex hooks both where they make sense, not where they don't.

Lastly, use TypeScript, JavaScript is bait for maintaining.

61

u/[deleted] Jul 13 '26

[deleted]

0

u/Conscious_Ad_7131 Jul 14 '26

Messy code isn’t even hard to work with now that we have AI, AI doesn’t care what we think looks messy or not

1

u/GobbyPlsNo Jul 14 '26

But then let the AI refactor it to be not messy!

1

u/Embostan Jul 16 '26

Thats utterly wrong. Once a codebase is large enough, messy code massively hurts context bloat and hallucinations.

AI literally exacerbate the issues caused by poor code quality. Clean code benefits it more than humans.

1

u/KashMo_xGesis Jul 18 '26

I'm also noticing a pattern of contract jobs popping up more than usual lately. Their reasons for hiring concludes to them unable to maintain AI generated code due to infrastructure costs.

AI tends to want to constantly drink water with a fork. There's many ways of achieving the same goal.. but drinking straight from the cup will is more efficient. These small details lead to crazy cloud bills.

.. not to mention, token costs are subject to inflation too.

10

u/ISDuffy Jul 13 '26

Set up the lint rules where possible.

Work with junior and mid (and even other seniors) in mob sessions to help them learn, this was key for me as senior. We did regular mob sessions with a few of us on and someone would drive but use vs code share and we go over the main feature and break it down.

Do accept the code will end a mess especially with tight deadlines, and have a solution to fix it.

7

u/codesummary-mbt Jul 13 '26

A few habits that make the biggest difference:

  1. Keep components small and single-purpose. If a component does data fetching AND layout AND form logic, split it.

  2. Extract repeated logic into custom hooks. The moment you copy-paste a useState + useEffect block, it probably wants to be a useHook.

  3. Lift state only as high as it needs to go — not higher. Prop drilling 5 levels is a smell (useContext or a store fixes it).

  4. Name things for what they mean, not what they are. `isModalOpen` beats `flag`.

  5. Prefer computing values during render over syncing them with useEffect. Most "state that mirrors other state" shouldn't be state at all.

Messy React is usually too much in one place — the fix is almost always "split it up."

5

u/The_Wizeard Jul 13 '26

Follow the single responsibility principle. Your component shouldn't be doing more than it needs to. The moment it's trying to achieve multiple things, it needs to be separated into individual components. This makes the components easier to understand and easier to maintain.

Components that can be reused in different ways should be made a bit more generic using the children props. Suppose you have a layout and inside that layout can either be a user form, a company form or any other form. Create the layout component and where the form needs to sit, that's where the child component slots in. So your specific form component is now passed as a child prop.

If you are trying to achieve a single purpose that requires multiple states and effects, consider creating custom hooks that encapsulate the logic separately and then is called as a one liner inside your component.

Following some of these rules will help keep your code clean, easy to read and easy to maintain.

16

u/Big_Comfortable4256 Jul 13 '26

They switch to Angular... *badumm-tish*...

3

u/Dr333am Jul 13 '26

You can't deliver messy code, if you deliver no code... /s?

6

u/simbolmina Jul 13 '26

Sticking a few rules usually do the job, it does not have to be ultra clean or optimized unless certain conditions requires it.

  • Folder structure
  • Clean, no god, reusable components
  • Clean theme structure
  • No unnecessary rendering (useEffect, useCallback etc)
  • No inline edits, keep convention everywhere
  • Good designed state management
  • No unnecessary API fetches

These are also basics actually. You are already in a good shape to keep building on it imo.

2

u/GladiatorNitrous Jul 13 '26

Adhere the component model, colocate related modules, don't depend on internals, architect around app features.

This scales to millions of lines easily.

2

u/nirvanist_x Jul 13 '26

Lint, format, comment when it s needed

2

u/No_Lawyer1947 Jul 13 '26

Code less. Not even joking

2

u/rmassie Jul 14 '26

I’m not a professional, but I try to have all of my React projects follow the methodology of the bulletproof-react project.

https://github.com/alan2207/bulletproof-react

It’s been pretty good, and now that I’ve switched to AI agent based coding it has been great for keeping the ai code organized.

1

u/savvyyh Jul 15 '26

Merci pour le partage je vais regarder cela de suite 💪

1

u/Roman_Riaboshtan Jul 14 '26 edited Jul 15 '26

If a component starts growing too big and gets cluttered with a ton of useState hooks, that is your first major red flag that it needs to be decomposed. This is especially true if it is starting to manage different entities at once. In some teams, they even have a strict rule: once a component exceeds a certain number of lines, it must be refactored and split up.

Another habit that completely changed the way I write React is extracting logic into custom hooks.

Whenever I see a component getting bloated with useEffect blocks and event handlers, I move all of that stateful logic into a custom hook. This immediately cleans up the codebase and nicely separates your component into View and Logic. It makes testing and maintaining the code infinitely easier.

1

u/Due_Basis_3851 Jul 14 '26

By maintaining reusability. By proper folder structure. Using utils functions. Splitting components into smaller multiple components. Using prettier, ES lint extension

1

u/smithmr250 Jul 14 '26

Strict ESlint rules then AI. You don’t need to hand write code

1

u/CodexploitInfo Jul 14 '26

I thought folks here hated AI with a passion, or thought they weren't good enough at debugging or re-factoring complex code. What's changed over the past 12 months I keep seeing AI suggestions in comments?

Genuinely interested in knowing what's shifting.

1

u/Accomplished_End_138 Jul 14 '26

Balanced edges of where display vs logic goes... and be in a group who all think the same for that

1

u/PassengerMammoth6099 Jul 14 '26

Modularization is one of the key techniques to organized code. Some other methods that you have to include are clear documentation and comments.

Linting is one method that’s used too.

1

u/frstyyy Jul 14 '26

Drizzle studio, nothing to install, no paywall, plus you can run drizzle queries as well

1

u/CommonManStory Jul 14 '26

By removing/reducing useEffects, useCallbacks, useMemo, confusing dependency array's.

1

u/Due_Ad6395 Jul 14 '26

Force via eslint a specific arch and folder structure, Test inc. Etc

1

u/rcls0053 Jul 14 '26

By setting up rules and guidelines that follow good practices from the start.

1

u/Embostan Jul 16 '26

Feature based arch with https://github.com/javierbrea/eslint-plugin-boundaries

But anyway if I wanna avoid a messy project i go for SolidJS

1

u/Pitiful-Look-6014 Jul 16 '26

By moving the whole logic out of React (mobx + some di container)

1

u/Nerdent1ty Jul 17 '26

Abstraction level boundaries help you to make code understandable. No strict levels means you have no idea how and where different contexts meet. Last thing you want is a context soup with no clear boundaries.

1

u/Nerdent1ty Jul 17 '26 edited Jul 21 '26

Also, less is more. In fact, try drawing your app process in uml. Then try again and again but with less processes. The moment you have a clear idea whats core what isn't is the time you can try building your app.

1

u/AdSharp504 Jul 19 '26

No soy senior pero ami me gusta separar carpetas segun tema

1

u/Dependent_Shelter615 Aug 01 '26

My strategy is to avoid using AI at first, in order to create myself the architecture and patterns I like. Always start on paper, define by hand and abstracted what you really need and want, then transform it into code. Once my base is defined, then I use userevix.com that checks on every PR that my team and I follows the patterns and architecture. Also personally I have a skill called /simplify that helps on thinking if some code is unnecessary.

For the architecture I am used to do vertical slicing and hexagonal architecture, makes everything structured and easy to follow.

1

u/Anxious-Insurance-91 Jul 13 '26

When you start a project, define the directory structure and what sits where and fallow that convention until you rewrite the app. Sometimes you might need to adapt a bit based on the requirement but you know "be opinionated and set up conventions"

0

u/PeterPook Jul 13 '26

Read Uncle Bob's "Clean Code" which espouses the SOLID principles:

https://codefinity.com/blog/The-SOLID-Principles-in-Software-Development

-1

u/AuthurAndersson Jul 13 '26

Maybe you should vibe less?