I'm not sure thats really true. In a different world, the react constructor functions would have access to `this.useState` and `this.useEffect` and then you could extract any logic you like by dispatching `yourFunction(this)`. HOC are not the only alternative design.
Hooks really push at the boundary of the language and I'm not sure they're an optimal path once you actually start dealing with state.
How do they push at the boundary? I feel like so many people talk about them being magical, but I don't see how they're any different than any other effectful function call. Is the idea of tracking call order that exotic?
This is a very simplified example of how hooks work under the hood:
let hookStates = [];
let currentHookId = 0;
let firstRun = true;
function endRun() {
firstRun = false;
currentHookId = 0;
}
function useState(initialValue) {
const hookId = currentHookId++;
if (firstRun) {
hookStates[hookId] = initialValue;
}
function setter(nextState) {
hookStates[hookId] = nextState;
}
return [hookStates[hookId], setter]
}
let actions;
function run() {
const [a, setA] = useState(1);
const [b, setB] = useState(2);
// this is done because we're not setting up event handling
// and we need some way to trigger external updates
actions = {setA, setB}
endRun();
return a + b;
}
function assert(received, expected) {
if (received !== expected) {
let error = new Error(`Expected ${expected}, but received ${received}`);
error.name = 'AssertionError'
throw error;
}
}
assert(run(), 3);
actions.setA(3);
assert(run(), 5);
actions.setB(5);
assert(run(), 8);
actions.setA(1)
actions.setB(-1)
assert(run(), 0);
I could understand thinking they're magical if you were under the impression you were the one calling the component functions rather than React, but I think my impression was always that it was still React's job to call the function component (otherwise, createElement seems like a waste). They might have at one point said that it was okay to do that in tests, but I'm not sure about that, and it would have been out the door the moment function components started supporting refs.
`useEffect(f, [])` runs on every render, but only installs the effect once. The other times its not installed. That means standard language facilities such as *closure capture* don't quite work as expected unless you pass them in that list `[]` too
Its not impossible to get used to it, but thinking in hooks is profoundly different than thinking with normal javascript.
I think the original design wanted so badly for state to fully live outside of React, but unfortunately, the information about what components are currently active on the screen is very relevant for what the state should be doing. As such, I think that approach just doesn't work no matter how much we'd like it to work.
Hooks make you run into those potential bugs head-first, and that's always seemed to me like what a large part of the "hooks are hard to reason about" complaints stem from. The other parts are people who expect functions to be invoked in a different way than they are. I don't really know what to tell those people beyond asking them if they've ever seen code calling a component directly.
Its not normal for a render function to run all the time but the closures mentioned in it to be completely ignored. Thats completely the opposite of how most other APIs work in the language. Usually, a (constructor) function runs once, and the closures returned by it may get run multiple times. Completely ignoring the passed closures to hooks in many/most cases is something very specific to React.
React function components are not constructor functions though, so I don't see how those are relevant. Bringing up the expectation that constructors "only run once" in the context of how hooks are hard to reason about seems strange though, as class component constructor functions have to be written in a way where they can potentially run multiple times. I think that's been a requirement for the entire time React has supported JavaScript classes.
What do you mean by "closures returned by a constructor function"? Do you mean the instance and its associated methods? If so, yes, running a constructor obviously produces one instance[1], which is true in React too. But you're never invoking that constructor yourself--and you never should have been doing that with React in the first place--so why would that matter?
Also, I'm confused, can you point at a comparable API to a React function component in the JavaScript language?
[1] well, sort of. Constructors can return any arbitrary object, so the following works
class Foo {
constructor(n) {
return new Number(n);
}
}
let foo = new Foo(1);
foo instanceof Foo; // false
foo instanceof Number; // trueI'm giving an example of whats a normal use case of closures. Running a single function once that creates closures that run zero, one, or multiple times is "normal". Running a single function multiple times that creates closures that run one time and get ignored all other calls of the function is not.
This exactly describes a leading-edge debounce function, which I was asked in multiple interviews early in my career to implement on a whiteboard. I'll admit that "problems people feel like giving to junior devs" isn't a great method of measuring whether or not something is simple, but I think it is indicative of how widely that sort of thing is expected to be understood. It also exactly describes any sort of request framework where request responses are cached after the first call and the result is returned without a network hit in subsequent calls.
My debounce implementation would *not* be trying to catter to some API that looks like this:
render() {
debounce(() => {
justCallCodeHere(); moreLines();
})
debounce(() => {
anotherFunction(); moreLines();
})
}
constructor() {
// called only once
this.debouncedFn1 = debounce(() => { justCallCodeHere(); moreLines(); })
this.debouncedFn2 = debounce(() => { anotherFunction(); moreLines(); })
}
render() {
// use the created debounced functions
this.debouncedFn1()
this.debouncedFn2()
}
I hope that illustrates the key weirdness aspect of hooks.