One danger of relying on open source technology from tech giants is that they tend to be somewhat focused on their own company’s problems. (Here, the performance of Facebook’s front page.) It can...
One danger of relying on open source technology from tech giants is that they tend to be somewhat focused on their own company’s problems. (Here, the performance of Facebook’s front page.) It can be nice to benefit from their work on tougher problems than you’re likely to have, but at the same time it’s often repurposing technology that’s more complicated than you need.
I think I just haven't experienced this mental backlash against thinking about hooks, and I can't say I'm totally sure why. I like hooks, much more than I like class component lifecycles. I find...
I think I just haven't experienced this mental backlash against thinking about hooks, and I can't say I'm totally sure why. I like hooks, much more than I like class component lifecycles. I find them substantially easier to reason about, even with effects and layout effects, and I find it much easier to figure out what a function component with hooks is doing than a class component with lifecycle methods.
I don't even think it's accurate to say that React hooks are contributing to the extent that React is a "black box". React hooks also feel to me like a more predictable/understandable API than lifecycle methods; hooks are functions that I call, that have predictable behaviors, while lifecycle components are functions that I define that something else calls. The order that they're called is opaque and arbitrary, and as a result the docs on class components are chock-full of footgun warnings.
React is a black box, to some extent; you could actually argue that the entire point of React is to be a black box. All declarative APIs are black boxes, that's what they're for: to abstract away the "how" and provide a simple "what" interface. But I don't think I buy that new features like hooks and Concurrent Mode are making it more of a black box.
Looks like useEffect installs a callback, though? It seems like there could be similar issues with knowing the order in which things are called. The article would be stronger with real examples of...
Looks like useEffect installs a callback, though? It seems like there could be similar issues with knowing the order in which things are called.
The article would be stronger with real examples of cases that confuse experts.
That's true, it does! There's actually an article that was making the rounds back in April that talked about trying to reason through code execution order with React hooks:...
That's true, it does! There's actually an article that was making the rounds back in April that talked about trying to reason through code execution order with React hooks: https://dillonshook.com/a-critique-of-react-hooks/
I think the weakest critique that this article makes is the one about code execution order. This was a real concern with lifecycle methods, where each method could be doing a number of unrelated things, and following the lifecycle of a state single value could involve reading multiple lifecycle methods in an arbitrary order. But the value of the useEffect hook is that it inverts that process and makes your effect declarations... well, declarative. Effects declare when they should be executed with a dependencies array: after the DOM commit cycle, each effect is evaluated, in order, and any effect whose dependencies have changed is executed.
The conceptual value of effects is that they're isolated snippets of logic, with a fully expressed set of conditions for when they should be executed.
On the other hand, I think that the first 3 points in that linked critique are very much legitimate, and have caused real frustration and difficulty with large systems at work that are owned by multiple teams!
On a purely theoretical level, no open-source library ever is supposed to be a black box. React isn't some abstracted API: it's that but also their engine. The idea of a black box is to build...
On a purely theoretical level, no open-source library ever is supposed to be a black box. React isn't some abstracted API: it's that but also their engine. The idea of a black box is to build something that can't be meddled with, in one way or other. Ideally, you wouldn't need to look into the workings of something like React when you're using it, but you can't be precluded from doing so.
One danger of relying on open source technology from tech giants is that they tend to be somewhat focused on their own company’s problems. (Here, the performance of Facebook’s front page.) It can be nice to benefit from their work on tougher problems than you’re likely to have, but at the same time it’s often repurposing technology that’s more complicated than you need.
I think I just haven't experienced this mental backlash against thinking about hooks, and I can't say I'm totally sure why. I like hooks, much more than I like class component lifecycles. I find them substantially easier to reason about, even with effects and layout effects, and I find it much easier to figure out what a function component with hooks is doing than a class component with lifecycle methods.
I don't even think it's accurate to say that React hooks are contributing to the extent that React is a "black box". React hooks also feel to me like a more predictable/understandable API than lifecycle methods; hooks are functions that I call, that have predictable behaviors, while lifecycle components are functions that I define that something else calls. The order that they're called is opaque and arbitrary, and as a result the docs on class components are chock-full of footgun warnings.
React is a black box, to some extent; you could actually argue that the entire point of React is to be a black box. All declarative APIs are black boxes, that's what they're for: to abstract away the "how" and provide a simple "what" interface. But I don't think I buy that new features like hooks and Concurrent Mode are making it more of a black box.
Looks like useEffect installs a callback, though? It seems like there could be similar issues with knowing the order in which things are called.
The article would be stronger with real examples of cases that confuse experts.
That's true, it does! There's actually an article that was making the rounds back in April that talked about trying to reason through code execution order with React hooks: https://dillonshook.com/a-critique-of-react-hooks/
I think the weakest critique that this article makes is the one about code execution order. This was a real concern with lifecycle methods, where each method could be doing a number of unrelated things, and following the lifecycle of a state single value could involve reading multiple lifecycle methods in an arbitrary order. But the value of the
useEffecthook is that it inverts that process and makes your effect declarations... well, declarative. Effects declare when they should be executed with a dependencies array: after the DOM commit cycle, each effect is evaluated, in order, and any effect whose dependencies have changed is executed.The conceptual value of effects is that they're isolated snippets of logic, with a fully expressed set of conditions for when they should be executed.
On the other hand, I think that the first 3 points in that linked critique are very much legitimate, and have caused real frustration and difficulty with large systems at work that are owned by multiple teams!
On a purely theoretical level, no open-source library ever is supposed to be a black box. React isn't some abstracted API: it's that but also their engine. The idea of a black box is to build something that can't be meddled with, in one way or other. Ideally, you wouldn't need to look into the workings of something like React when you're using it, but you can't be precluded from doing so.
Obligatory link to the suckless principles.
When you build massive APIs with as many features as React, this is an inevitability.