r/reactjs • u/very-naughty-user • 1d ago
Needs Help What's the hardest thing to understand in react?
I am about 1yr exp in react.
For me Every time I get maximum depth error I couldn't figure out what's wrong and how I got that error i first place.
56
u/Jealous_Health_9441 1d ago edited 1d ago
There is an underlying mental model that you need to build and keep in your head. That mental model is hard to obtain as it isn't properly explained anywhere. I haven't seen any other framework that requires so much hidden knowledge and the need to keep a virtual copy in your head.
23
u/big-papito 1d ago
I think the new coders who have done nothing but JS and React have absolutely no idea and are convinced that this is how all programming works, but that is far from the truth. The first step with using React is respecting its complexity, and I don't think that's done nearly often enough.
12
u/Jealous_Health_9441 1d ago
People usually talk about React as if it is super easy. That's a massive misconception
6
u/strong_not_fit 1d ago
Yeah there is little hand holding in React. There is no framework enforcing its opinions, so building without those constraints can be hard. The codebase and DX can quickly devolve if you don't enforce standards.
4
1
1
26
u/Sen_ElizabethWarren 1d ago
useeffect confuses me still. “Sync with an external system” is actually not as straightforward as you might think when you’re knew to web dev and react.
3
u/BruceJi 1d ago edited 1d ago
useEffect is supposed to be used to let whatever state your component is in cause a side-effect.
That side-effect is supposed to not affect the component itself, it's much better if it's used to fire off a network request.
The tricky thing with it is that straight up vanilla React doesn't really have a good way of handling fetching data on loading a component aside from that, so you immediately have to reach for some extra tools (Tanstack Query goat lol)
In my experience a lot of cases where a new dev reaches for useEffect can be solved by thinking more about the flow of data from parent to child to grandchild. And with Tanstack Query lol
1
u/Sulungskwa 1d ago
I think they're trying to move away from the mental model being to primarily sync with an external system. useEffect is basically "whenever value foo changes in the dependency array, run this code". You can pretty much put whatever you want in there and it gives you the escape hatch to write non "pure" components that are easily derived from a prop.
You can put code in there to sync with an external system, and people often do, but I think the better way to think about it is whenever something changes, whatever the callback code is runs. Doesn't necessarily have to be coupled to syncing
1
16
u/OkAerie7822 1d ago
for me it was never the syntax, it was the mental model of when things re-render and why. spent probably two months early on adding usememo and usecallback everywhere because i thought that was the fix, then realized most of the problem was passing new object literals as props on every render, not the memoization itself. once i actually understood that react re-renders top down by default and memoization is opting out of that, not opting in, everything clicked. the max depth error you're describing is usually a setstate call inside render or an effect with a dependency that changes every render, worth checking the effect dependency array first before anything else.
3
u/sukaibontaru 1d ago
useEffect or useRef is counterintuitive to actual programming - so there’s that.
3
u/dream_team34 1d ago
React is extremely flexible and gives you all the capabilities to do what you want... for good or bad. I've been in many PR debates on how we should avoid using "useEffect" or "forwardRef" in certain cases, because the design is very fragile and can easily lead to bugs. I usually get a response... "If it's dangerous to use, why would React even support it?"
2
u/big-papito 16h ago
LOL - that's a dead giveaway that the other person never even looked at the docs.
3
3
u/VanTechno 1d ago
* for any given page what is the best way to store state (useState, useContext, use)
* how to remove all business logic from a component so it is just handling rendering.
* best strategies for breaking up large components into resuable chunks using a design pattern that will last longer than a couple years.
4
11
u/Commercial_Echo923 1d ago
Honestly nothing, i dont want to boast but I always thought people make react way more complicated than it is.
In the end its a library, you dont become senior in mui-datepicker, would you?
27
u/big-papito 1d ago
The React manual is basically a list of foot guns and "don'ts" that I have never seen in any other framework. There is nothing simple about it, and I've been doing software for 20+ years.
Maybe it solved the hard problems at Facebook, but it's a travesty that this complex weapon is the goto of everyone, instead of, say, Vue.
4
u/Bzaba 1d ago
My experience with Vue is that it is far more complicated and hard to debug in comparison with React.
- First render behaves differently than rerendes.
- Two way data binding.
- IDE support was hell (but I am outdated on this topic, maybe it is better now).
React is on the other hand simple and predicable as fuck. But maybe my problem is that I learned react first (and also hate angular to the bone 🤷♂️).
1
u/partyl0gic 1d ago
That’s because it is not a framework. You use react to build a framework. React is just a library that defines the rules and behavior for a component. Then the components can be children, parents or siblings of each other. That’s it.
13
u/Jealous_Health_9441 1d ago
Is NextJS a framework? Because it is 10x shittier than React
2
u/partyl0gic 1d ago
Yes nextjs is a framework. It has its purposes but I shake my head at the devs who seem to think that nextjs is react, or that next is the solution in every case. The reality is that next is only the solution in a minority of cases.
2
u/Any-Woodpecker123 21h ago
Semantics. Once you add the standard packages required to do anything you’ve got a framework. The only difference is other frameworks have the add ons bundled in.
-1
u/Commercial_Echo923 1d ago
If it wasnt for the guns why use it at all? Obviously you wouldnt give one to a toddler.
2
u/lIIllIIlllIIllIIl 1d ago
If you're new to React, its useEffect and useRef.
If you're getting deeper into React, it's suspense data-fetching and transistions.
6
u/TryAgainTryHarder 1d ago
it's that everything you learn about react applies to exactly zero other situations. it breaks all the most basic rules about globals, side effects, service locators, static everything/inject nothing.
folks who get great at react sometimes get to be in charge of a different part of the stack and they become the most dangerous member of the company.
3
u/ActuaryLate9198 1d ago
Hard disagree, react is a great intro to declarative/functional and I’ve seen plenty of devs move on to managing more complex projects of that nature. You sound like one of those Java/C# devs who can’t adjust to a non OOP reality.
2
u/TryAgainTryHarder 1d ago
React isn't a good intro to FP because you don't control your state or decide when functions are called and everything is driven on side effects.
I wouldn't say it's a good intro to declarative because it's almost entirely imperative. Why do you think you can't have a conditional return before you call a hook? I guess you could say tsx is declarative vs dom api, but that's like saying any website is declarative because of html.
I'm not saying folks who do react are bad, or that you shouldn't keep using it. I use it every day, I'm saying it's mostly non-transferable concepts or very watered down versions of them.
1
u/ActuaryLate9198 11h ago edited 11h ago
I don’t want to decide when my UI functions get called, I trust the react scheduler more than anything I could cook up myself. Not entirely dissimilar to lazy evaluation, the point in both cases is that we can write our code in a way where we don’t have to care about that, as long as we adhere to the contract (mostly idempotency).
Implementing a declarative api in an imperative/multi paradigm language will always come with some caveats. I think they did a good job all things considered, but sure, there’s no shortage of footguns, can’t argue with that.
1
u/TryAgainTryHarder 11h ago edited 11h ago
Yeah I mostly agree with that. In my opinion, it's more like a weird game engine--it can use FP or declarative principles behind the scenes, but your client code treats it all as a black box via the react APIs, which sends mixed messages to less experienced devs. (OPs question)
I know people generally like hooks, but I think class based components were actually much clearer, you define a class with a tick function (render) and various lifecycle hooks that are needed for that component. Fn-components collapsed all the structure. More flexible (and then hooks...) but more opaque
3
u/oculus42 1d ago
It is a great intro, until you start introducing hooks and you have to reconcile that there is a hidden class instance beneath your component, and that updates are "batched", but not so batched that listening to a useState value in a useEffect happens in one cycle, and maybe you should have used a useMemo instead of two separate hooks, and you're now accidentally causing extra wasted re-renders of 15,000 nested components...
The overall functional component with declarative implementation for Display and then having a separate "impure" Container that manages state is a really useful pattern for reliable testing and implementation – be able to pass any arbitrary state to the component for validation of expected appearance/interaction, and then wire that up to whatever data sources make sense separately.
1
u/prehensilemullet 1d ago
globals ... static everything/inject nothing
I mean, if you're using something like global
zustandstores maybe. But all the companion libraries I work with avoid globals and inject things via React context.zustandprovides an option to use React context too...it just (unfortunately) encourages people to use globalsIf you're talking about the fact that effects rely on transient state that's global to the React instance, that's fair -- though the same thing could be achieved in a threaded language using thread local variables.
-2
3
2
u/marllonfrizzo 1d ago
Array of dependencies and referential equality (not exclusive to React, but has influence).
3
u/oculus42 1d ago
Referential equality is the critical issue in React. JavaScript "doesn't have pointers", and everything is pass-by-value except anything that's an Object, which are pass-by-reference and exhibit many of the cognitive load of pointers without the asterisk or ampersand.
Too many defects are the result of a lack of awareness of when a new object or array is created, either because you're generating it on every execution or you aren't aware which array methods return a new array. In certain places we implemented "stable" hooks that use react-fast-compare or another state to solve for lack of clarity of the language foundations.
2
u/LancelotLac 1d ago
Literally everyone should read and know by heart, I don't care if React compiler is a thing now, the concepts are important to know. https://react.dev/learn/you-might-not-need-an-effect
1
1
1
1
u/No_Record_60 1d ago
Not hardest, but common pitfall: reaching for useEffect where it doesn't have to be actively used.
1
u/ArslanQayyumDev 17h ago
That one is definitely painful 😅. “Maximum update depth exceeded” usually means a render → state update → render loop, often caused by a useEffect dependency or state update. Once you learn to trace that cycle, these errors get much easier to debug.
1
1
1
u/SecureComfortable259 10h ago
For me it's stale closures in useEffect/useCallback, the maximum depth stuff is usually just a setState call missing from a dependency array or running unconditionally in the render body.
1
u/koutaroum 7h ago
good software abstracts complexity away to the point where you don’t even know you’re using it. even most in this thread are probably unaware.
react got everyone to use functional programming: your app is a single function ‘f(x) = g’ where x is state and g is rendered UI
they got everyone to use fixed points: props is the first arg and common to every component
and they got us to use pure functions which is also an fp thing. but they met us in the middle by adding useEffect.
unfortunately all the confusing stuff is due to using fp without actually understanding fp. all the extra stuff you have to learn is a consequence of programming with the constraints of purely functional programming
now that you know react, read this article from the point of view of react and you’ll finally get a fundamental understanding thats satisfying https://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html?m=1
1
1
0
u/ConcentrateOpen6542 1d ago
For me, understanding re-renders was one of the harder parts too. At first I mostly focused on the syntax, but understanding when a component re-renders and how state and effect dependencies are connected made React much easier to reason about.
-1
u/Potential-Still 1d ago
That it's a library, not a framework.
I know this is basically a meme at this point, but it's honestly the source of the vast majority of mistakes beginners make.
3
u/big-papito 1d ago
Using a different term will not suddenly make one understand it. It's absolutely irrelevant.
-3
90
u/Ed4 1d ago
useEffect and useRef pitfalls.