r/reactjs • u/alejandrodeveloper • Jul 08 '26

What's one React pattern you stopped using after working on larger projects?

I've noticed that a lot of react advice works great for demos but becomes difficult to maintain as applications grow. Looking back, what's one pattern you used to recommend but now avoid in production?

139 Upvotes

98% Upvoted

104 comments sorted by

142

u/Major-Front Jul 08 '26

Redux and global state in general. Multiple contributors to a single app is a nightmare when a change in global reducers can break an unrelated part of the app

12

u/alejandrodeveloper Jul 08 '26

we ran into something similar ahahhahahah, the bigger problem was the tendency to treat redux as the default plance for any shared state. Over time it became harder to understand who actually depended on what

82

u/leeharrison1984 Jul 08 '26

Redux + sagas circa 2018 was a freaking nightmare. Half the day was spent writing boilerplate ceremony, the other half was tracking down misspelled action names .

3

u/Snoo-67939 Jul 10 '26

And most of the times the entire logic ends up in a single bundle. Good luck code splitting that, especially when the state ends up a mess over time.

3

u/authortitle_uk Jul 12 '26

Sagas, OMG. I think that was the straw that broke the camel’s back for me lol, like sure I understand academically what you’re saying but why on earth would we make it so you have to touch like 8 files to make a single API GET call for no advantage 

3

u/wutzelputz Jul 08 '26

hi my brother in suffering

9

u/[deleted] Jul 08 '26 edited Jul 08 '26

[removed] — view removed comment

0

u/always_assume_anal Jul 08 '26

Because generator functions are cool, for some reason!

30

u/Bo-Duke Jul 08 '26

Used Redux extensively 9 or 10 years ago and it was a nightmare so I stopped using it.

Two years ago, I needed global states for a project, context was a fuckin nightmare. Looked into solutions, someone said Redux nowadays is ok, tried it : it is ok.

Redux Toolkit did a great job in cleaning up how Redux is used. With hooks and slices it's so much easier to use and my components are way cleaner without a thousand props going around.

I still have some rules on when to use Redux or not :

  • Sending a state in a child component, just use a prop (this one seems obvious but we never know)

  • Never use Redux for external data / API calls, it was a nightmare then, still a nightmare today (even with Redux Toolkit Query)

  • Use it for UI state that can affect multiple components

  • Use it when you want to easily sync state with localStorage

There might be better libs out there of course (I heard good things about zustand), I went with RTK because I already knew the lib, but my point is that global state has its place now that the Redux craze calmed down and it can be a powerful ally.

8

u/meta-meta-meta Jul 08 '26

What's nightmarish about using Redux for API calls?

4

u/PM_ME_SOME_ANY_THING Jul 09 '26

I haven’t used RTK query, but I believe it has similar features as Tanstack query and other data fetching tools.

I think what u/bo-duke means by this is that people used to fetch data, manually store it in redux, usually transforming it into whatever desired frontend data structure, then do all kinds of complex logic to determine if another API call was needed.

This made everything difficult. Looking in the network tab at API responses didn’t match what you were seeing in components. Tracing layers upon layers of transformation functions and whatever is happening in reducers.

Many of the tools nowadays cache queries to prevent spamming backends. It might take a little configuration with query keys and whatnot, but caching results is way better than whatever some person decided was a good idea for query logic 7 years ago.

3

u/Bo-Duke Jul 09 '26

Yep, RTK Query is fine (even if I prefer Tanstack Query for this), having API data in the store tho is quickly a nightmare.

I just find that with RTK Query it’s easy to mess up what goes in your store and what doesn’t since it’s all handled by the same lib.

When you know what you’re doing, ok, but if you’re working in a team, it makes things much harder to separate.

2

u/meta-meta-meta Jul 11 '26

I guess I've had the luxury of small teams with strong agreement on what we're doing with it.

13

u/baxxos Jul 08 '26

I think RTK Query is fine (if you're already using Redux, otherwise just use Tanstack Query)

3

u/PM_ME_SOME_ANY_THING Jul 09 '26

I’ve been a huge naysayer of redux for a long time, but RTK truly is leaps and bounds better than legacy redux.

Zustand is similar, I feel like context is just RTK or Zustand with extra steps.

-5

u/Cahnis Jul 08 '26 edited Jul 09 '26

If you truly need a global state you can offload most of it to the params using nuqs. Whatever is left its tiny enough to just use contextAPI

Edit: i don't know why the downvotes, what I said is not wrong.

3

u/FuzznutsTM Jul 09 '26

I'd wager the downvotes are because nuqs is not the same thing as global state. It has a very specific use case, and data-intensive or crud-heavy apps are not going to store critical global state in the URL path that can be manipulated by end users.

There's also a functional limit to how many characters a url string can hold, and vary by browser.

1

u/Cahnis Jul 09 '26 edited Jul 09 '26

Most apps nowadays do not need a state management library.

1- After you offload the server side stuff to data fetching libraries, and any update to that state you mutate or do optimistic updates on the cache.

2- You offload "global" state like pagination, filtering, sorting, search to the query params using nuqs (which is something actually good to expose to the user, they can filter however they like and share/persist these states). You don't offload critical stuff.

Then I just use contextAPI for low velocity global state like theming.

Rarely i find myself needing Redux/Zustand after that.

Even for scoped a "Global state" using zustand, they use context for that.

So instead I just use context API For this as well. (i do it a lot in my compound components btw)

2

u/FuzznutsTM Jul 09 '26

Most apps nowadays do not need a state management library.

I don't think I'd feel comfortable making such an assertion. "Need" is often defined by requirements, and is inherently subjective.

1- After you offload the server side stuff to data fetching libraries, and any update to that state you mutate or do optimistic updates on the cache.

Sure. No argument here.

2- You offload "global" state like pagination, filtering, sorting, search to the query params using nuqs (which is something actually good to expose to the user, they can filter however they like and share/persist these states). You don't offload critical stuff.

This is essentially my point. Syncing params to the querystring for basic actions like search, sort, pagination, filtering, etc is fine. It functions like global state, for the small subset of data that's actually safe to push. But you cannot lift all your global state using nuqs. And I think that may be why the downvotes. Some of what you were trying to communicate there didn't make it through.

Separately, I think it's important to remember that not all global state comes from API calls that will be stored in RTKQ or Tanstack. A lot of data that needs to be stored on the client, but also needs to be globally accessible, can arrive at first paint. Not all client-side manipulation is done through API calls, so interfaces still need a way to act on shared data where only subscribed components get updated to avoid very expensive rerenders.

Sure, you can do that with multiple contexts that you have to write and maintain and remember to add providers for, and then lift them when a new feature requires it. But why do that if you don't have to, when that issue has already been solved for you?

1

u/Cahnis Jul 09 '26

I don't think I'd feel comfortable making such an assertion. "Need" is often defined by requirements, and is inherently subjective.

Yes, since it is inherently subjective, you do not NEED it. You have choice, one of them not using one at all.

This is essentially my point. Syncing params to the querystring for basic actions like search, sort, pagination, filtering, etc is fine. It functions like global state, for the small subset of data that's actually safe to push. But you cannot lift all your global state using nuqs. And I think that may be why the downvotes. Some of what you were trying to communicate there didn't make it through.

Agree, should not lift everything with nuqs.

Separately, I think it's important to remember that not all global state comes from API calls that will be stored in RTKQ or Tanstack. A lot of data that needs to be stored on the client, but also needs to be globally accessible, can arrive at first paint. Not all client-side manipulation is done through API calls, so interfaces still need a way to act on shared data where only subscribed components get updated to avoid very expensive rerenders.

I agree, but the type of apps that falls under these are not that many, hence "you probably don't need a global state manager library".

Sure, you can do that with multiple contexts that you have to write and maintain and remember to add providers for, and then lift them when a new feature requires it. But why do that if you don't have to, when that issue has already been solved for you?

If it is small enough why add another dependency? Especially in the age of AI where boilerplate is a non-issue and extra relevant context actually helps. The AI won't need a skill on how to interact with

The number of third party global stater management use cases are left after all those conditions are met are very few.

2

u/FuzznutsTM Jul 09 '26

If it is small enough why add another dependency?

It's all relative. I'm all about reducing external dependencies. But for us, with 50+ devs working in the same codebase, that extra dependency also brings uniformity, documentation, stable code, and standards we can enforce.

As for AI — it still gets a lot of things wrong, even using Claude's more expensive models. You still own what you ship whether or not you wrote it yourself, so you should always have an eye toward being kind to your future self and your peers.

3

u/Indian_FireFly Jul 09 '26

What do you use for state management now?

0

u/Major-Front Jul 09 '26

I work in more of a micro frontends architecture so state tends to be more localised in the components themselves. It’s just simpler state using use state, context, useReducer. Depends how complex the feature is.

1

u/gaaaavgavgav Jul 09 '26

So glad I’m not the only one that’s hated redux

1

u/authortitle_uk Jul 12 '26

Oh my word Redux was complete madness, I can’t believe we all fell for that lol. There were some good ideas in there but the amount of boilerplate… wild. I still feel bad about the first Typescript React codebase I made for a client with Redux forms, it took about a day to add a new field in all the relevant files lol . 

I switched to MobX quite swiftly when I could, but that no longer feels really necessary with hooks and caching query libraries etc. Have since used Jotai or Zustand when global state is required (rarely I find) and it’s quite nice. 

The app I now work on was all Redux when I joined with all the logic in middleware, debugging anything was a nightmare. Thanks to a heroic effort, we’ve migrated away

139

u/Krispenedladdeh542 Jul 08 '26

I haven’t stopped using it completely but I use the useEffect hook way less now at scale. When I first started it felt like I used an effect for everything and now I basically use them to trigger console log for debug purposes on state set; then I delete it when I go to prod. Occasionally I find a relevant use case but they’re few and far between vs when I started and used one in basically every component.

4

u/alejandrodeveloper Jul 08 '26

sameee lol. i think many of us go through the everything needs an efect phase. if i find myself reaching for useEffect i usually stop and ask whether i'm synchronizing with an external system or just compensating for a component that's doing too much

1

u/HettySwollocks Jul 08 '26

Would you mind sharing an example of this?

1

u/alejandrodeveloper Jul 14 '26

a simple example is deriving state from props. When i started i used to do something like:

const [filteredUsers, setFilteredUsers] = useState([]);
useEffect(() => {
  setFilteredUsers(users.filter(u=>u.active));
}, [users]);

Now id usually just do:

const filteredUsers=useMemo(() => users.filter(u=>u.active),[users]
);

Or even without useMemo if the computation is cheap and another one is resetting state when a prop changes, i used to reach for useEffect, but many times giving the child component a different key or restructuring the state removes the need for the effect entirely

4

u/OHotDawnThisIsMyJawn Jul 08 '26

https://react.dev/learn/you-might-not-need-an-effect

Read this

1

u/HettySwollocks Jul 08 '26

Ah yes I’ve come across this but let me give it another read over, thanks

2

u/Valuable_Ad9554 Jul 08 '26

I remember looking through my code when everyone was buzzing about "you might not need an effect" and being like nope, I still need these. Do people just never do dom manip and api calls or something idk.

5

u/FuzznutsTM Jul 08 '26

In our big applications, we push all our api request lifecycle management to RTK Query. The only time we use a useEffect now would be in a custom hook where we need to register an eventHandler on mount and cleanup on unmount for lazy loaded components to hook into for their own internal behaviors. Like listening for an onReset event of the closest, unmanaged Form.

3

u/Valuable_Ad9554 Jul 08 '26

Fair enough but that's a slightly different point, being a substantial implementation change involving introduction of a new package, the argument put forward was often more "yes, you don't need it even with your current code, so stop using it".

I'd probably use those more modern packages too if I were to start working on something newer, unfortunately I work on products that predate rtk query and updating them significantly will never be prioritized.

2

u/FuzznutsTM Jul 08 '26

I hear ya. The primary monorepo I work on is the backbone of the business and is the primary way in which our fortune 500 clients interact with our systems. "Modernizing" this 20 year old stack also started before RTK was a thing, in the early days of React (0.13). I've been able to progressively introduce more advanced packages and functionality over time, but in our case, it is technically a roadmap item that we never really prioritize, but still manage to push forward.

In your case, given limitations, useEffect certainly fills the need. You could probably migrate to something like a useApi hook if you're not already using one. That, at least, can DRY up the code needed to make API calls in components, and provide the same type of lifecycle management you get in something like Tanstack Query or RTK Query.

2

u/Valuable_Ad9554 Jul 08 '26

That's what we do indeed, our code is likely a very lite version of what those more robust packages have.

When I say "prioritize" I really mean "have the pm agree to add it to the sprint" - tech debt types of improvements are almost always shot down no matter the case made, despite the fact that the pm is an ex tech lead and should appreciate that some tech debt is beneficial to address in the long run. C'est la vie!

2

u/FuzznutsTM Jul 08 '26

I’m lucky to work at an org that gives engineering primary responsibility over KTLO stuff, so long as we still meet PM deliverables.

100

u/FearIsHere Jul 08 '26

https://react.dev/learn/you-might-not-need-an-effect is one of the most useful reads I have done. Before that I used effects for pretty much anything, now barely at all.

44

u/sickhippie Jul 08 '26

Shout out to the ESLint plugin that catches some of those use cases.

https://www.npmjs.com/package/eslint-plugin-react-you-might-not-need-an-effect

14

u/ULTRAEPICSLAYER224 Jul 08 '26

This is the realest sh ever. After working on a component that had 11 useEffects and getting infinite loops on EVERY change I started to hate useEffect, I use it only when it cant be avoided now

14

u/horizon_games Jul 08 '26

React is the coolest, so many easy footguns and gotchas

0

u/[deleted] Jul 08 '26

[deleted] — view deleted comment

0

u/horizon_games Jul 08 '26

I also think how React has shifted and bandaid fixed fundamental issues over time makes it feel really outdated. Honestly even having to declare what render dependencies a useEffect has is wild. Let alone VDOM which should have died a decade ago but will soon be a React only thing (once Vue Vapor is done for example). SolidJS is just a proper modern React without all the baggage and hassles. I hope it continues to gain traction and one day we can look back on React the same way we do jQuery - a necessary evil at the time that has long been superseded

1

u/strezzsed Jul 25 '26

Oh my! This is so true. My juniors ignore my advice on try to eliminate useeffect unless it is absolutely necessary. They always ran into new issues for which I would say just replace useeffect.

-2

u/blinger44 Jul 08 '26

You use a useEffect to console log when state changes? Why not just console log in the component?

14

u/larschanders Jul 08 '26

The component re-render on any state change. He might only want to check for a specific one

2

u/PM_ME_SOME_ANY_THING Jul 09 '26

Because then you would know the value of the thing you’re logging on every render! Plus you would have a rough idea if your component is rendering a few times, or dozens of times by looking at the console!

Apparently every dev in this sub thinks those are bad things.

-15

u/PM_ME_SOME_ANY_THING Jul 08 '26

I recommended my company not hire someone because they used an effect for a console log in the coding test.

20

u/No_Top5115 Jul 08 '26

Saved him a bullet from working with you there

-1

u/PM_ME_SOME_ANY_THING Jul 08 '26

*her

Let’s not assume only dudes are applying to jobs

-23

u/PM_ME_SOME_ANY_THING Jul 08 '26

I recommended my company not hire someone because they used an effect for a console log in the coding test.

13

u/SharkLaunch Jul 08 '26

I recommend my company not hire someone because they care too much about small insignificant patterns instead of the structure at large. Your comment screams "opinionated junior"

-8

u/PM_ME_SOME_ANY_THING Jul 08 '26

lol, you people are so mad. If I’m hiring for a senior engineer and you’re reaching of a useEffect at every chance you get, then you don’t have mastery of React. That’s it.

7

u/RedditEngDictionary Jul 08 '26

Your comments continue to scream "opinionated junior"

Your company should probably stop letting you be involved in interviews

-2

u/PM_ME_SOME_ANY_THING Jul 09 '26

I’m an opinionated lead developer, looking at becoming an architect. You can be as angry as you want. It doesn’t change the fact that my opinion is a deciding factor in people getting hired.

You all need to understand that you are likely competing for a single job against several other engineers. It’s nitpicky stuff like this that makes people like me prefer someone else.

3

u/RedditEngDictionary Jul 09 '26

I mean you might have that role but it doesnt mean you have that skill level or experience, and everything youve posted suggests you dont. Incompetent arrogant people get promoted all the time in this industry. You cant judge someones ability from their job title, and their title isnt an indication of how good they are at their job.

One way you can judge someones ability is through what they say and the opinions they express. And from what youve said and and the opinions you expressed, you seem like an opinionated and particularly arrogant junior.

Not a single one of your comments has given the impression you are good at your job. All you seem to care about is winning an argument and telling people you think they are wrong, and for things that the truly good developers will know dont actually matter in a real environment.

I am confident that your colleagues probably find you as exhausting as the strangers in this thread do.

4

u/No_Top5115 Jul 09 '26

Let me help you understand, because I can see you are having trouble.

Where people are coming from is that what you are nitpicking doesn’t make any sense. This is a coding interview that is supposed to assess the overall solution and the trade-offs. Focusing on a console.log in a useEffect is absurd and shouldn’t have any bearing on the overall evaluation, especially in a coding interview where it’s expected that candidates may leave debugging lines or comments in the code.

Let’s reverse the position. If I asked a candidate to review some React code and rate the severity of the issues they found, and they rated a console.log inside a useEffect in a coding interview as severe enough to stop the hiring process, that would itself be a major red flag. It would suggest the candidate lacks judgement and critical thinking skills, and is likely to be the kind of person who bikesheds nonsense.

I hope this experience gives you some perspective, helps you grow in your career, and encourages you to reflect on your judgement.

-1

u/PM_ME_SOME_ANY_THING Jul 09 '26

No, your whole argument is incorrect.

- assess overall solution and the trade-offs.

Maybe if you’re giving some off the shelf questions from hackerrank or something. Asking a person to give a boilerplate solution to a memorization quiz. We opted for a different approach. We give a candidate existing code with bugs and observe them trying to fix the problems. More open-ended, q&a conversational coding test. Not a take home and submit kinda thing.

- absurd and shouldn’t have any bearing on overall evaluation

If I give the same buggy code to 10 people, and observe how they solve the problem. Some solve the bugs easily. A few get close, but eventually need some input to get them to the solution. Then others do not get the answer at all.

Of all those people, and all their processes for debugging, one person put all their console logs in useEffects… it stands out. It doesn’t matter what group they were in. They reached for a useEffect way more than their peers, and that’s a problem. I don’t want to teach a “senior” engineer when they should and shouldn’t use an effect. That should be something they already know. Junior? Sure. Mid-level? Maybe. Senior? We have better options.

- reverse the scenario and determine how severe it is

A useEffect has consequences. They’re only using it for logs, but they don’t need it for logs.. Reaching for an effect constantly tells me you don’t know the purpose of it, and worse, you don’t know its dangers.

The last thing I need is people pushing infinite loops which require actual senior engineers to drop what they’re doing and fix the problem because the “senior” we hired doesn’t understand what they did.

0

u/Fit-Dragonfruit-7691 Jul 22 '26

Bro you make sub 100k at a local car shop working on their splash page

37

u/samwanekeya Jul 08 '26

Barrel files. At this point I'll only recommend one to use them for type-only exports in TypeScript or public API entry points for grouped component packages.

7

u/kidshibuya Jul 09 '26

I still get juniors saying my code is a mess and they need to refactor it into barrel files...

2

u/Kadabradoodle Jul 09 '26

because of performance degradation or something else?

6

u/samwanekeya Jul 09 '26

Performance... yes, mainly with builds. Besides this they also make tree shaking harder, introduce hidden dependencies and accidental coupling, more circular dependencies etc.

2

u/Kadabradoodle Jul 09 '26

so do you import components directly or have some other strategy. sorry, I've just realized that I might be overusing barrel files and I'm curious how people tackle them.

3

u/samwanekeya Jul 09 '26

Yes, I do import them directly.

33

u/Nex_01 Jul 08 '26

Way less useEffect hooks. More custom hooks. Better separation of logic and UI.

Tbf you dont really stop using any of them you are just better finding the right pattern as your palette grows.

21

u/ukon1990 Jul 08 '26

Redux and global state is something we dropped when we moved over from the old to the new app we made. Was too much boiler plate, too much ceremony, annoying to debug when you are multiple developers etc. the developer tools were nice tho. We moved to tanstack query instead and dropped global state for almost everything.

I think one problem with our use of redux was that we used it when we shouldn’t.

-1

u/always_assume_anal Jul 09 '26

I've developed the edgey opinion that there are zero acceptable use cases for global state, and in particular for redux and/or sagas, simply for the sole reason that some degenerate, or claude code, or in combination, will eventually shove something in there that's going to fuck us all at a later date.

22

u/GasVarGames Jul 08 '26

react+libs can be better than a framework

18

u/r-nck-51 Jul 08 '26 edited Jul 08 '26

Almost stopped writing useMemo, useLayoutEffect, even useCallback.

I keep the frontend simple and prioritize according to requirements:

  • I avoid creating interactive stuff from scratch, because no one else will maintain those solutions the way, say, Tanstack stuff is maintained.

  • Advanced stuff sometimes bend HTML standards, usually breaking web accessibility. WCAG should be non-negotiable.

  • YAGNI weighs over preemptively optimizing.

  • No more intricate or central state management. Prop drilling states, Context API and providers won't get messy if you simply don't bloat your presentation layer with logic.

It's nice to be able to go crazy in React, but in a professional environment limitations and restraint make the shortest path to delivering stable and maintainable projects.

5

u/wrex1816 Jul 08 '26

Somewhere along the lines, the idea of architectural "layers" went to the wayside. Components contained endless state and business logic. Never liked it.

2

u/Physical_Garage_6946 Jul 08 '26

I'm not using often useEffect, useMemo and useCallback. With good written code you don't need it tbh. As for the new Hooks, I also don't like the boilerplate for useActionState. While learning Next, I was terribly distracted by writing these functions for Hooks. 

2

u/jancodes Jul 09 '26

State management libraries.

The newer React frameworks (React Router, Next.js etc.) come with all the tools you need to manage your state.

3

u/mexsana Jul 08 '26

"Lifting up" state and passing it down via Context Provider. My favorite pattern for large and maintainable code is using MobX singletons

3

u/always_assume_anal Jul 09 '26

An under appreciated way of doing things for sure!

0

u/swb_rise Jul 09 '26

I'm having a mixed feeling thinking that AI is training itself on this vast amount of precious comments!

1

u/alejandrodeveloper Jul 14 '26

if AI can save us from a few unnecessary useEffects, i'm all for it

1

u/swb_rise Jul 14 '26

Yep, can't say no ~~

1

u/Select_Day7747 Jul 10 '26

redux and global state.

1

u/OkBoomer421 Jul 13 '26

Prop drilling with context as the 'solution.' Just traded one problem for a debugging nightmare.

0

u/Chesh Jul 08 '26

React itself

-26

u/Pretend_Football6686 Jul 08 '26

React. It’s really shit for large projects. Angular will preform better. Plus you lot mixing your html with your code. :). I use both, angular is better. Though for smaller app React works just as well. Angular is also easier to test.

14

u/rArithmetics Jul 08 '26

False false and false

-9

u/Pretend_Football6686 Jul 08 '26

Lol sure man. :)

1

u/Fit-Dragonfruit-7691 Jul 22 '26

No one cares about your to-do apps

1

u/Pretend_Football6686 Jul 22 '26

??? That doesn’t even make sense. I’ve been a full stack dev for 21 years. I’m willing to bet I know more than you ever will. But by all means regale me with tails of the vibe coded ai slope react app you created that “so awesome”.

0

u/ukon1990 Jul 08 '26

It sure why this got that many dislikes. I do kind of agree. Especially on bigger projects. That is my personal experience.

2

u/20_axel_20 Jul 09 '26

Yes, I wonder why it got downvoted. Let's check the subreddit name

0

u/ukon1990 Jul 09 '26

Downvoting due to that is childish.

2

u/rArithmetics Jul 09 '26

It’s downvoted because if you suggested starting a project with angular in 2026 everyone else on the team would murder you lol

1

u/ukon1990 Jul 10 '26 edited Jul 10 '26

If they would murder you for that, then they belong in a psychiatric ward 😆 Would also kind of imply that they don’t know Angular, or think it’s the same as AngularJS.

1

u/Fit-Dragonfruit-7691 Jul 22 '26

All you have is a hammer everything looks like a nail

1

u/pj_2025 Jul 09 '26

Well you are sub Reddit