3 ms·

Hooks are more magic than I prefer, they behave in an unusual way compared to normal functions. But overall I like React more with Hooks compared to the previou

Hooks are more magic than I prefer, they behave in an unusual way compared to normal functions. But overall I like React more with Hooks compared to the previous state. One really important aspect here is that Hooks don't just replace class components, they also replace the need for higher order components in many cases. And they make it much easier to compose stateful behaviour in React components.

markplindsay 5y ago
Using hooks to integrate 3rd party libraries is so much cleaner than using HOCs. The magic (and the learning curve, which I think is where much of the pushback on hooks comes from) is worth it.
munchbunny 5y ago
The magic is usually what gets to me. Stuff like useState depending on the order it was called under the hood, meaning you have to use it a specific way. On the one hand, it really does clean some things up well, like for higher order components, but also I find the magic just leaks more than I’d like, and as a result I feel like the only way use the magic safely is to study all of the pitfalls. It’s like using C++ smart pointers but a bit less foot-shooty.
- fabian2k 5y ago
  While this is kinda weird, I didn't find the dependence on the order of the hooks problematic. The most natural way to use hooks is also the correct one, at least for me. What is a bit tricky is useEffect, but I found that in many cases I either didn't actually need it, or I can use libraries for common tasks that hide the more complex parts. Using react query for data fetching simplified those parts considerably, and I never have to write a useEffect to fetch data from the server.
- agumonkey 5y ago
  oh wow, if pure functions become hidden-order dependant again then the way is broken.
  - jolux 5y ago
    First of all: useState is not a pure function, nor is setState. I would think that’s obvious from the name. The order isn’t hidden and it’s not magic, it’s the order they’re defined in the function body, because under the hood the React runtime is storing all the hooks you call in an array and firing them off by iterating through the array. It is a very conventional architecture in event handlers: of course there is going to be an order they get called in, there is no way to avoid it. But it’s perfectly explicit.
    - imtringued 5y ago
      >because under the hood the React runtime is storing all the hooks you call in an array and firing them off by iterating through the array. I must correct this. Pay attention to this function [0] It's just a plain linked list and nothing is being fired off by iterating through the linked list. When you call a hook react either creates a new node in the linked list or it pops the current head off the linked list so that the second hook will get the second element, the third hook the third element and so on. The hooks are fired off by calling them. React isn't calling them again. Each render simply calls your component function and your function calls the hooks which runs a reducer [1] on the internal queue of the hook to compute the latest state. The second return value is just pushing elements into the internal hook queue. [0] https://github.com/facebook/react/blob/e07039bb61e3d006ad552ab7754acbc91f7b8619/packages/react-dom/src/server/ReactPartialRendererHooks.js#L139 https://github.com/facebook/react/blob/e07039bb61e3d006ad552... [1] https://github.com/facebook/react/blob/e07039bb61e3d006ad552ab7754acbc91f7b8619/packages/react-dom/src/server/ReactPartialRendererHooks.js#L266 https://github.com/facebook/react/blob/e07039bb61e3d006ad552...
      - jolux 5y ago
        Yes, you're right. Iterating is not the right word, and it's the ordering of the data in the internal queue that I was thinking of, which is fixed by the order in which the hooks are called. During rendering, your component itself will run through the queue. It's not React doing it.
- imtringued 5y ago
  I have seen a lot of crappy blogs that try to explain how useState works and they were all highly misleading. They try to explain things with closures and other random made up stuff. The code isn't simple but the way it works is much simpler than what these blogs show. 1. React uses a bunch of global variables during rendering to make the current component and its hooks available to a global function (useReducer). Basically a react specific "this" 2. Hooks are stored in a linked list, meaning the first hook that is called gets the first hook's data. If you have hooks A,B,C and disable B then C will get B's data. 3. The way hooks themselves work is that all hooks call useReducer and the hook state is just a queue that is fed into the reducer which is called whenever useReducer is returning the latest state as the first returned value. 4. The second returned value is just a function that pushes a new entry into the queue.
thatswrong0 5y ago
> Hooks are more magic than I prefer But they aren't really magic.. I think the rules of hooks makes it pretty easy to guess how hooks might work under the hood. The fact that they need to be called in the same order every time indicates to me that the could, perhaps, be some sort of hidden array attached to each component instance that keeps track of whatever the hook needs. Each hook call increments the hidden index it accesses by one. It's a bit odd from the perspective of normal Javascript, that's for sure, but we're already pretty far from that because we're working within the React runtime.
- imtringued 5y ago
  Here is how it works: https://news.ycombinator.com/item?id=28972892 https://news.ycombinator.com/item?id=28972892 https://news.ycombinator.com/item?id=28972973 https://news.ycombinator.com/item?id=28972973

markplindsay 5y ago

Using hooks to integrate 3rd party libraries is so much cleaner than using HOCs. The magic (and the learning curve, which I think is where much of the pushback on hooks comes from) is worth it.

munchbunny 5y ago

The magic is usually what gets to me. Stuff like useState depending on the order it was called under the hood, meaning you have to use it a specific way. On the one hand, it really does clean some things up well, like for higher order components, but also I find the magic just leaks more than I’d like, and as a result I feel like the only way use the magic safely is to study all of the pitfalls. It’s like using C++ smart pointers but a bit less foot-shooty.

fabian2k 5y ago
While this is kinda weird, I didn't find the dependence on the order of the hooks problematic. The most natural way to use hooks is also the correct one, at least for me. What is a bit tricky is useEffect, but I found that in many cases I either didn't actually need it, or I can use libraries for common tasks that hide the more complex parts. Using react query for data fetching simplified those parts considerably, and I never have to write a useEffect to fetch data from the server.
agumonkey 5y ago
oh wow, if pure functions become hidden-order dependant again then the way is broken.
- jolux 5y ago
  First of all: useState is not a pure function, nor is setState. I would think that’s obvious from the name. The order isn’t hidden and it’s not magic, it’s the order they’re defined in the function body, because under the hood the React runtime is storing all the hooks you call in an array and firing them off by iterating through the array. It is a very conventional architecture in event handlers: of course there is going to be an order they get called in, there is no way to avoid it. But it’s perfectly explicit.
  - imtringued 5y ago
    >because under the hood the React runtime is storing all the hooks you call in an array and firing them off by iterating through the array. I must correct this. Pay attention to this function [0] It's just a plain linked list and nothing is being fired off by iterating through the linked list. When you call a hook react either creates a new node in the linked list or it pops the current head off the linked list so that the second hook will get the second element, the third hook the third element and so on. The hooks are fired off by calling them. React isn't calling them again. Each render simply calls your component function and your function calls the hooks which runs a reducer [1] on the internal queue of the hook to compute the latest state. The second return value is just pushing elements into the internal hook queue. [0] https://github.com/facebook/react/blob/e07039bb61e3d006ad552ab7754acbc91f7b8619/packages/react-dom/src/server/ReactPartialRendererHooks.js#L139 https://github.com/facebook/react/blob/e07039bb61e3d006ad552... [1] https://github.com/facebook/react/blob/e07039bb61e3d006ad552ab7754acbc91f7b8619/packages/react-dom/src/server/ReactPartialRendererHooks.js#L266 https://github.com/facebook/react/blob/e07039bb61e3d006ad552...
    - jolux 5y ago
      Yes, you're right. Iterating is not the right word, and it's the ordering of the data in the internal queue that I was thinking of, which is fixed by the order in which the hooks are called. During rendering, your component itself will run through the queue. It's not React doing it.
imtringued 5y ago
I have seen a lot of crappy blogs that try to explain how useState works and they were all highly misleading. They try to explain things with closures and other random made up stuff. The code isn't simple but the way it works is much simpler than what these blogs show. 1. React uses a bunch of global variables during rendering to make the current component and its hooks available to a global function (useReducer). Basically a react specific "this" 2. Hooks are stored in a linked list, meaning the first hook that is called gets the first hook's data. If you have hooks A,B,C and disable B then C will get B's data. 3. The way hooks themselves work is that all hooks call useReducer and the hook state is just a queue that is fed into the reducer which is called whenever useReducer is returning the latest state as the first returned value. 4. The second returned value is just a function that pushes a new entry into the queue.

thatswrong0 5y ago

> Hooks are more magic than I prefer But they aren't really magic.. I think the rules of hooks makes it pretty easy to guess how hooks might work under the hood. The fact that they need to be called in the same order every time indicates to me that the could, perhaps, be some sort of hidden array attached to each component instance that keeps track of whatever the hook needs. Each hook call increments the hidden index it accesses by one. It's a bit odd from the perspective of normal Javascript, that's for sure, but we're already pretty far from that because we're working within the React runtime.

imtringued 5y ago
Here is how it works: https://news.ycombinator.com/item?id=28972892 https://news.ycombinator.com/item?id=28972892 https://news.ycombinator.com/item?id=28972973 https://news.ycombinator.com/item?id=28972973