> This is yet another JavaScript paradigm to learn. For the record, I am a 49-year-old React fanboy. I am a freelancer and use other frameworks apart from React, and this gives me fatigue. Amen to that. The fact that still are in "here's a 'better' idea, let's try this" landscape in JavaScript is depressing. I no longer jump on these new frameworks when the bandwagon flies by. I ignore postings for jobs saying they a…
Interesting way of thinking - hooks _are_ a new framework, they are just marketing it under the same name.
I guess I'm old too. When someone shows me what (real) pain hooks solve on non-Facebook-size codebases, I'll be all ears. Until then... Thank you, classes work just fine and make my code nice and readable.
I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand. OP seems to be a bit stuck in a hole. If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. B…
I certainly found on one occasion where I felt I had to break the laws of hooks, that it worked much better split into two components.
I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.
The issue I have with the "rules of hooks" is that it makes some previously trivial things cumbersome at best, and downright complicated at worst. For a quick example, something as simple as mapping an array onto a series of elements with a callback requires (as far as I can tell) that the inner element be broken out into its own component that calls `useCallback`, since you can't create a unique callback for each it…
You don't need to use hooks there. You can just define your functions and be done with it.
I'd argue that hooks didn't really make anything better, they just replaced the pitfalls with different obtuse pitfalls and unergonomic solutions. Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCa…
I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.
I've found that the hoop jumping type stuff, while potently annoying, can at least be abstracted into a custom hook (and then mocked in tests) easily so that the code is clean.
Coming from the FP world, hooks are a terror because they break all the nice rules functions are supposed to uphold. Hook components don't necessarily return the same value when given the same arguments, making them impure (stateful). The benefit of function components IMO has always been that you can use the function scope as a container for pure, stateless rendering logic. With the introduction of hooks I can no lo…
How does the existence of hooks preclude you from using function components without state (without any hooks)?
They don't, but before I could look at a function component and go "ah, a nice stateless component" whereas now I have to wonder whether the _function_ contains _state_
The issue I have with the "rules of hooks" is that it makes some previously trivial things cumbersome at best, and downright complicated at worst. For a quick example, something as simple as mapping an array onto a series of elements with a callback requires (as far as I can tell) that the inner element be broken out into its own component that calls `useCallback`, since you can't create a unique callback for each it…
You don't need to use hooks there. You can just define your functions and be done with it.
You do if you don't want those child components to be re-rendered needlessly when some higher-level state changes.
Coming from the FP world, hooks are a terror because they break all the nice rules functions are supposed to uphold. Hook components don't necessarily return the same value when given the same arguments, making them impure (stateful). The benefit of function components IMO has always been that you can use the function scope as a container for pure, stateless rendering logic. With the introduction of hooks I can no lo…
Nothing stops you from using pure function components, and you should where possible. But eventually, you need to hold state somewhere. You don't need to put it in your components, but you do need to deal with it. If anything, hooks are a nice middle ground where the behaviour becomes declarative.
My personal opinion is that state should be contained in some sort of class or data structure, separate from functional architectures where the notion of state is generally avoided. So my usual suggestion would be to use either a class component (or redux or insert favorite state mgmt solution here) for your state, and then inject the state as props to your function components
Many people aren't event aware of the unnecessary renders caused by using hooks. If your app is so tiny that it doesn't matter if everything renders all the time, then you might not be aware of your `useCallback` recreating callbacks way too often ( https://github.com/facebook/react/issues/14099 ), or that you're not even using it in the first place. Considering that front end is probably the area of software develop…
A lot of people don't understand that React's default behavior is to re-render _everything_. When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that care…
> re-renders that having consistent callback function references matters
That's the case I was talking about, I probably should have added that. In our codebase at work most components are using such optimizations but of course that's not the case for most people.
Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: ( https://reactjs.org/docs/optimizing-performance.html ) > Internally, React uses several clever techniques to minimize the number of costly DOM ope…
Could you elaborate? Rendering perf is pretty much the least of my concerns, even on my apps which support IE10. Most "perf" problems I find are related to fetching and appropriately caching data.
It's pretty easy to run into render performance issues with React, especially on older machines, when you have a very dynamic UI. At work, we dynamically generate several SVG charts and "badges" on certain pages. Putting even one of those onto a page without any optimization created about a half second delay between actions on my high-end machine, so we had to spend some time making sure that things weren't re-rendering needlessly and that DOM nodes were getting reused. But even if that seems like an atypical use case, we had similar issues rendering complex tables, purely due to the amount of DOM nodes needing to be put onto the page at once. So it might not be an everyday kind of problem, but I don't think it's uncommon to run into performance issues with React.
How does the existence of hooks preclude you from using function components without state (without any hooks)?
They don't, but before I could look at a function component and go "ah, a nice stateless component" whereas now I have to wonder whether the _function_ contains _state_
If you see "useWhatever"... then it has a hook.
And you already have to wonder if a function has state if you didn't write it. If you did, you should know.