51–60 of 139 posts
I'm done with React. They keep re-inventing the wheel, and every iteration is full of issues that need to get resolved with yet another design principle.
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…
“Just burn it to the ground and start over,” isn’t an inspiring endorsement of the methodology...
I have run into a sort of useEffect hell at times that makes me wish for the old life-cycle components as visually I find them easier to comprehend in very "active" and more complex components. But honestly I suspect that is because I don't quite understand useeffect well enough.
It can easily be solved by just setting the state in the event handler, since the state is included in the dependencies array for the fetch effect:
https://codesandbox.io/s/dependency-array-0u3sc
The answer to this question posed by the author?
> On line 23, the useFetch Hook will be called once on the first render. On lines 35 – 38, pagination buttons are rendered but how would we call the useFetch Hook from the event handlers of these buttons?
We can call `useFetch` again by triggering a re-render. This hasn't changed at all with the introduction of hooks: new props or new state still triggers a re-render.
They didn't click for me until I read this netlify blog post: https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-rea...
If you think of them as mostly just syntactic sugar for closure state variables wrapped up in the module pattern, it's not so bad. (This is how some of us have been writing D3.js code for years!)
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 don't understand the hate against class based components. React class-based components are dead simple to understand.
It more-or-less boils down to: 1. class-based components force your lifecycle logic to live in disparate locations. 2. Class-based hooks are obtuse with hidden gotchas whereas pure functions tell you exactly what they're doing. 3. A whole class of unergenomic solutions disappears when you use hooks.
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 are rewriting their system in "new Framework Y!". I don't care how "pure" your new design is, I care about having it work well in the trenches.
I, too, am tired.
And old.
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 don't understand the hate against class based components. React class-based components are dead simple to understand.
You have more control too. Look at the parameters to useState to see what I mean.