Didn’t read the article, but I have to rant a little bit.
Working with `useEffect()` is so fucking miserable. It’s a bit like owning a car where the gaps between the panels are just slightly too far apart; there’s always the possibility that some data is out of sync because React inexplicably decided to run a thing a tick later than you expected. “Effects” don’t actually mix with with the old class component methods, insofar as you’ll never be able to get an effect to run before component methods, so you end up having to gasp do side-effects in render against a bunch of “refs” to achieve some semblance of object permanence.
The implication behind the naming of “synchronous effects” as `useLayoutEffect()` is laughable, as though the only time you would ever want to run some code synchronously is for “layout” purposes. My guy, JavaScript’s security model is based on execution, you can’t copy to the clipboard, request full-screen/picture-in-picture, do countless privileged operations outside the synchronous execution of a native click handler, for instance, and we’re going to place all these use-cases under the umbrella term “layout?”
React applications are weird, shuddering messes, where callbacks fire senselessly based on “dependency arrays.” Heaven forfend you turn off linting which helps you not violate “the rules of hooks,” and even when it’s on there are countless gotchas about default parameters and callback functions which are recreated every render. At no point will you ever be able to correctly source the initiator of a “render,” because someone in their infinite wisdom decided to unroll the JavaScript call stack as a queue. Stepping out of a component in a debugger always places you in the same `while` loop and you’re left wondering where on Earth did this execution start. I don’t understand how programmers could be so ignorant of how useful a call stack is, and the React team essentially has to recreate call stacks in error messages and Devtools. Seasoned React developers have all seen “React minified error #185,” or “Maximum update depth exceeded.” This is essentially a stack overflow error, except of course they did away with the stack. It’s not normal for stack overflow errors to be happening as frequently as happens in React applications, and this is just when you’re lucky enough to get a warning; a lot of times the page will just hang and no one except your poor users will know.
I find it truly disturbing how professionals can make their and everyone’s lives so difficult, how deeply disconnected React is from the actual practice of programming, which is all about understanding how your code executes. My mind is boggled by 5 by 5 zoom calls of well-paid “staff engineers” chatting about React and writing tutorial upon tutorial like any of this normal. And these are the loud ones. I pray for the entry-level programmers, the contractors, the voiceless, who aren’t beefing on Twitter, who do not have a sense of how strange this kind of development is and don’t have the courage to speak up.
My work seems to have made you angry which makes me sad.
You’ll at least be happy to learn that useEffect will be sync if the render itself was sync in React 18. Ofc if you do an async render those effects won’t work anyway and you need to do it in the event handler itself.
I doubt it’s much of a conciliation though. I agree the programming model is weird. It’s the best idea we had for what we were trying to achieve. Sorry for the trouble it has caused you.
My primary issue is that you guys did have other options. You did. I saw the RFC thread. About 2/3s were useless "oh no" or "oh yes" comments, but about a third had suggestions and feedback, some good feedback, on how to make the stateful function API not as jarring and not as weird. You simply ignored it all, since you already had an API in mind (and perhaps already did most of the work, I don't know)
That you thought (correctly) that an eslint package of rules was necessary to prevent people from shooting themselves in the foot with the gun you have provided should have been a hint that it's not good API.
I understand all the hook rules and all the gotchas around stale closures. But I don't want to have to deal with those as part of my everyday, regular programming, it's just stupid. React is no longer productive and hooks are way out of control. Did you know hooks are even more stupid with concurrent mode on?
I think you’re using useEffect without an actual reason to use useEffect.
I’ve worked on large react projects for 4 years and I’ve only had to use useLayoutEffect once.
Sounds to me like you need to learn how to use React as a library and not as the only solution your app uses. Guess what: you can absolutely write plain JS (or Jquery etc) alongside your React components.
Working with `useEffect()` is so fucking miserable. It’s a bit like owning a car where the gaps between the panels are just slightly too far apart; there’s always the possibility that some data is out of sync because React inexplicably decided to run a thing a tick later than you expected. “Effects” don’t actually mix with with the old class component methods, insofar as you’ll never be able to get an effect to run before component methods, so you end up having to gasp do side-effects in render against a bunch of “refs” to achieve some semblance of object permanence.
The implication behind the naming of “synchronous effects” as `useLayoutEffect()` is laughable, as though the only time you would ever want to run some code synchronously is for “layout” purposes. My guy, JavaScript’s security model is based on execution, you can’t copy to the clipboard, request full-screen/picture-in-picture, do countless privileged operations outside the synchronous execution of a native click handler, for instance, and we’re going to place all these use-cases under the umbrella term “layout?”
React applications are weird, shuddering messes, where callbacks fire senselessly based on “dependency arrays.” Heaven forfend you turn off linting which helps you not violate “the rules of hooks,” and even when it’s on there are countless gotchas about default parameters and callback functions which are recreated every render. At no point will you ever be able to correctly source the initiator of a “render,” because someone in their infinite wisdom decided to unroll the JavaScript call stack as a queue. Stepping out of a component in a debugger always places you in the same `while` loop and you’re left wondering where on Earth did this execution start. I don’t understand how programmers could be so ignorant of how useful a call stack is, and the React team essentially has to recreate call stacks in error messages and Devtools. Seasoned React developers have all seen “React minified error #185,” or “Maximum update depth exceeded.” This is essentially a stack overflow error, except of course they did away with the stack. It’s not normal for stack overflow errors to be happening as frequently as happens in React applications, and this is just when you’re lucky enough to get a warning; a lot of times the page will just hang and no one except your poor users will know.
I find it truly disturbing how professionals can make their and everyone’s lives so difficult, how deeply disconnected React is from the actual practice of programming, which is all about understanding how your code executes. My mind is boggled by 5 by 5 zoom calls of well-paid “staff engineers” chatting about React and writing tutorial upon tutorial like any of this normal. And these are the loud ones. I pray for the entry-level programmers, the contractors, the voiceless, who aren’t beefing on Twitter, who do not have a sense of how strange this kind of development is and don’t have the courage to speak up.