2021-06-23
1094
#react
Paul Cowan
55900
Jun 23, 2021 ⋅ 3 min read

React Hooks: The good, the bad, and the ugly

Paul Cowan Contract software developer.

Recent posts:

Vite Adoption Guide Overview Examples And Alternatives

Vite adoption guide: Overview, examples, and alternatives

Vite is a versatile, fast, lightweight build tool with an exceptional DX. Let’s explore when and why you should adopt Vite in your projects.

David Omotayo
Nov 29, 2023 ⋅ 16 min read
Implementing Advanced Features With The Navigator.Share API

Implementing advanced features with the navigator.share API

Explore advanced capabilities for content sharing with the navigator.share API, including dynamic content sharing, custom share targets, and batch sharing.

David Omotayo
Nov 29, 2023 ⋅ 10 min read
Chas Peacock Leader Spotlight

Leader Spotlight: Scaling for the next phase of growth with Chas Peacock

We spoke with Chas to get his insights on building technology and internal processes for companies that are scaling quickly.

Jessica Srinivas
Nov 29, 2023 ⋅ 7 min read
Cypress Adoption Guide: Overview, Examples, Alternatives

Cypress adoption guide: Overview, examples, and alternatives

Cypress is one of today’s foremost tools for testing web applications. Let’s explore when and why you should adopt Cypress in your projects.

Paul Akinyemi
Nov 28, 2023 ⋅ 10 min read
View all posts

One Reply to "React Hooks: The good, the bad, and the ugly"

  1. I’ve found useState() to be nerve wracking and strange. It gives me more of what I don’t need, and the whole Hooks framework takes away things that I depend upon.

    I depend on the ‘this’ object in class components. The object is created when the component is first used, and stays in existence until it vaporizes. I put a lot of intermediate and calculated variables in it. I also have references to important data structures in it. You could call these ‘state’, except really they never change, or rarely change, or, somehow, labeling them ‘state’ just doesn’t seem right.

    Say I’ve got some state, in this.state. When these variables change, I need to go thru a lot of calculations to form data structures that render() can use to draw with. render() also happens when props change, but no recalculating needs to be done then. Where do I keep those intermediate data structures? Just toss them and recalculate every time there’s a render? I store them on ‘this’.

    I have references to large data structures that are shared among half a dozen or more other components. Many components all have a reference to some of those data structures for easy access while the software is running. This is why I like a ‘this’ object – I can set those references and not have to rebuild my network of references every render, reaching thru this object to get the reference to the other object, from which I get another object I need. Do I throw all this info into a cave in the hopes that next time this instance of this component is called, it’ll return to me the exact same instances I threw into the cave?

    All this goes way beyond the little toy examples I see for hooks. I have interdependencies between data in components that aren’t conveniently nested inside each other. You type in different numbers here, and the graphics over there changes. I have WebGL graphics that don’t redraw with the rest of the DOM, and cross-frame communication with other iframes.

Leave a Reply