This is a LinkedIn screenshot, sry if I cropped it too tight

React works by maintaining a virtual representation of the DOM. When you dispatch state changes into the virtual DOM react can determine which components depend on the change and which side useEffects run.

My gripe is that YouTube tutorials teach that the useState is the equivalent of a variable. This encourages average developers to problem solve solutions that end up using React’s Virtual DOM for business logic. The YouTube tutorials have react devs planting 100s of useStates - some of which don’t directly induce a visible-on-screen rerender - and then ⅒ as many useEffects to bind these states together. This means that for the Virtual DOM to come to the conclusion as to what html elements need to be changed and how it has already mutated 20-50-100s of times and the CTO tells me the react app is slow and they’re mad.

If 2 states have the opportunity to mutate each other back and forth then the truth is that you have 2 perspectives of the same state. And React gives you solutions for that - proper solutions - the useReducer hook is for defining these complex state mutations and the Context API for communicating that state to any component.

And this has me quintuple pissed off because these same tutorial grade react devs install REDUX as compulsively as a pack-a-day smoker (that’s #3). They use Redux to file variables in JavaScript memory (that’s #4) like it’s a global variable and rarely if ever use it for the complex state mutations they need instead I’ve seen react devs write components pull state out of redux into a component just so it can mount useEffect and process the state and dispatch the result back into redux. Let’s not even bring up how the react-redux binding library literally uses the React Context API (that’s #5).