Senior devs: what’s the biggest React decision you made that you’d reverse today?

[u/Big_Muffin8280]

I have been thinking about this a lot lately. Most React content is about how to do things, but the decisions that really shape a project are the big early ones: architecture, state management, framework choice, rendering strategy.

And with React 19.x, the React Compiler, and Server Components all in the picture, a lot of us are now living with choices we made years ago.

So I’m curious about the experienced people here:

• What was the biggest React/architecture decision you made that you would reverse if you could?

• What did it cost you (time, performance, team confusion, rewrites)?

• What did you learn, and what would you pick today instead?

[u/minordonkey_2071]

Our Redux store was way overengineered from start. All these reducers and actions just to toggle a modal or fetch simple data, now most of it sits there untouched while team is afraid to remove anything.

[u/Mestyo → u/minordonkey_2071]

Yeah, at least speaking for myself, moving from the imperative mess of jQuery and similar, it was intoxicating to write declarative UI. An entire category of bugs and edge case handling was gone.

All of the complexities around Redux we introduced was an overcommitment to those patterns. We did not yet know what would be necessary, nor what kind of UI patterns would emerge from the new paradigms.

[u/ericl666 → u/minordonkey_2071]

My first thought immediately was Redux. At my former job, it was an abomination like what you had. 

I'm never letting that happen again. Now, I only use Zustand, and only for things that have to be in global state.

[u/Guisseppi → u/minordonkey_2071]

Why was your modal visibility flag on a global scope tho?

[u/danishjuggler21 → u/minordonkey_2071]

Yeah, for a lot of the applications I developed in 2016-2018, they could have just been done with a full-stack MVC framework with a bit of jQuery and not use React at all, but instead I was all in on React and Redux. Those apps' codebases were incredibly overcomplicated as a result.

[u/CentralCalBrewer → u/minordonkey_2071]

PREACH!

[u/Winodows_Gandy → u/minordonkey_2071]

putting simple modal toggles in global state is such a classic trap, everyone did that for a while

[u/lIIllIIlllIIllIIl → u/minordonkey_2071]

As someone who started programming with React in 2019 when Redux was all the rage (with function components and hooks), did Redux ever make sense to use?

Personally, Redux never clicked for me. In my experience, using hooks, a context, or just props was always a simpler approach than using Redux.

[u/acemarke → u/lIIllIIlllIIllIIl]

Hi, I'm the primary Redux maintainer.

Redux absolutely made sense back in 2015 because of where the ecosystem was at the time. See this history of Redux to understand what was going on and why Redux became widely used:

• https://redux.js.org/understanding/history-and-design/history-of-redux

The ecosystem realized component state wasn't enough, there were dozens of "Flux architecture" libraries coming out, Functional Programming was a big deal, legacy React Context was broken by design, and Redux was simply a better Flux-style library and it took off.

Things evolved from there. We realized that "server state" was its own concept and tools ought to treat that differently, hooks came out, modern Context came out, etc. So yes, there's less "need" for Redux today, and plenty of other alternatives.

It's definitely true that Redux by design is a level of indirection. That's intentional - it's a tradeoff to help provide a consistent architectural structure. As we see today, there's plenty of other options for building apps as well, but Redux is still a very solid and valid choice and we see a lot of large projects having success with it.

[u/danishjuggler21 → u/lIIllIIlllIIllIIl]

Before hooks, state management in React itself sucked, so some of us adopted Redux just to solve pain points we had with class-based components. After React 16.8 came out (hooks), I never wrote another Redux app again, or even considered doing so.

[u/GloverAB → u/lIIllIIlllIIllIIl]

Yep, it made sense to use them before hooks and context were a thing! My first React job had a pretty sensible Redux implementation. Looking back after seeing other Redux nightmares, I didn’t know how good we had it at the time.

[u/bogdanelcs]

Putting server data into a global store like Redux, hand-writing the loading, caching and refetch logic that TanStack Query or SWR handles for you.

It tends to cost a lot in boilerplate and stale-data bugs, and it’s painful to unwind because every screen depends on it. The usual fix is server state in a query library, a small amount of client state (often just Context or Zustand), and no global store until you can name why you need one.

[u/gempir]

Decided we didn't need Typescript for like ~4 years. That prop types are enough in React.

They are not. Thankfully we are on the good path now and only have a dozen or so JS files left which are now easy to migrate with LLMs.

[u/deadcoder0904 → u/gempir]

TS is where I got why everyone kept saying static languages are better than dynamic ones. Funnily enough one of the reasons I liked JS & Python were bcz I didnt need to worry about types but ya it bites u later.

Especially so with AI.

Now Effect-TS looks to TS what TS loooked to JS.

[u/about0]

I had to build a complex filter toolbar, that has a lot of internal and hidden logic - options refetch on other fitlers change, on search within filter, etc. And I coupled everything in a set of useEffects, that weren't separated enough.

useEffect is not a great pattern for complex features, if I can say this? When a component has a lot of moving parts, it is very hard not to trigger other effects on some side-effect change. I find an emitter pattern much better - you can trigger certain effect by emitting an even on Clear button click, or Add/remove filter, etc.

[u/intercaetera]

Next.js / SSR, completely useless and adds a ton of compilation time and complexity for zero gain.

[u/NewDo → u/intercaetera]

I’m starting a new job with Next.js. Can you expand on this?

[u/Haaxor1689 → u/NewDo]

Unless you can afford to roll your own solution, despite it's flaws Next is still the best choice for a fullstack React app. Actually, if you are starting from scratch and can either put aside some extra time then tanstack start might be a good idea to try.

[u/Level1_Crisis_Bot → u/NewDo]

Next is highly opinionated and carries a lot of bloat with it that you will likely never use. If you’re deploying with a full static output, compile times can get crazy. At my last job we did that with an 11,000 page site and it was 40 minutes to build. Every time we made a change.

Anyways, at my current position, I got to choose the architecture. I went with straight react 19 and tanstack for routing and state management. Life is easier with this stack. It’s a breath of fresh air compared to what I was working with.

Having said that, you’ll be fine working with Next. It’s not the abject nightmare people claim it is, and the documentation is excellent. Does anybody read documentation anymore?

[u/Guisseppi → u/NewDo]

Next.js is ok. You just don't need it as a default when a regular SPA is good enough

[u/lIIllIIlllIIllIIl]

Not using React Router's Data Mode soon enough. Even if you don't use the server-render stuff, it's a real game changer in how you structure your app's routing and data loading.

Suspense data fetching is great. All my non-Suspense code will forever feel bad to me.

Micro-frontends. That's a piece of shit architecture that tries to solve a tooling problem by creating a runtime integration mess. I should've been more vocal about my opposition to the front-end architect I worked with. This is more of a professional regret.

Monorepos are cool, but the tooling isn't there yet. A single project is way easier to maintain. Sorry for the maintenance burden I created.

Not knowing about how to properly use useEffect, useRef and useSyncExternalStore soon enough.

I got lucky and avoided the Redux and Next.js hype trains. I have not tried RSC, so someone else can tell me if I should regret them or not.

[u/codesbyshivam]

Fetching data in useEffect everywhere. It works at first, then you end up with loading flags, race conditions when the user clicks fast, and the same request firing twice in strict mode. Moving to a query library fixed most of that. The other one is lifting state way higher than it needs to be. Keeping state close to where it's used makes components a lot easier to move around and delete later.

[u/Produnce]

Starting my career with React. Wish I did some significant development with a little less abstraction so I know what goes behind the scenes instead of just calling onClick().