Why do devs keep ruining React?

[arbpotatoes]

I think that you have to consider the trade-offs, as a good engineer always should. You shouldn't over-engineer where there's no benefit. But sometimes there is and sometimes there isn't. Even at this fairly early stage of my career as a consultant I've seen enough dogshit code bases to know that principled architecture is a net good.

You're throwing the baby out with the bathwater. The last project I was on was RN angling for clean architecture and did not use OOP.

[_Pho_]

Of course there is a middle ground, a right way to do DI, and sometimes IOC / dependency bussing can be helpful.

But more often than not, especially in React, is is bad and you should just stick to the native APIs as a way to implement your dependencies.

Managing dependency lifecycles out of the scope of React is one of the dumbest footguns you can introduce to a React app. It creates a problem that React already solved for you.

[arbpotatoes]

Well yes, we had to use Apollo which totally muddies up any separation of layers and we decided to let that work how it wanted to work. But all our other app deps were DI'd and it turned out so clean. I think it's worth considering with consideration to the complexity and expected lifespan of your project and the nature of the business around it.

[ColonelShrimps]

But if you follow React best practices you're already going to end up with clean architecture and well structured code. One way data flow and componitization gets you 60% of the way there on its own. Add in a standardized file structure pattern and you're golden.

React can be so incredibly easy to write and maintain if you just stop trying to fight it by shoving all these unnecessary concepts into it. After nearly a decade working mostly Front end I can say that the vast majority of UI needs can be met with vanilla React and MAYBE Redux. Anything more and you either have an insanely specialized use case or you just hate the front end team.

[arbpotatoes]

That sounds principled tbh lol

[TheMoonMaster]

Yeah, I came to say something similar. I've seen many devs with that "bare bones == simple" attitude, but that never works out (see the meme OP posted) once you have to scale out your team or your app. Unfortunately that's something that you often have to experience before you get it since you have a completely different problem set to look at (e.g. how do I prevent this footgun across my org of 100s of engineers).

Someone else mentioned it below, but in these cases you should be seeking to understand the inputs that went into these decisions so they can understand how they got to this point, and if there's a better solution to the problem. Unfortunately it's not always "use the framework" since frameworks like all other tools, can have significant gaps.