5 ms·
Just a few more thoughts to add: When I see code like count++; setContent(<p key="counter">The count is {count}</p>); I immediately think about how s
by justin_murray 2y ago
Just a few more thoughts to add:
When I see code like
count++;
setContent(<p key="counter">The count is {count}</p>);
I immediately think about how someone, at some point, will introduce bugs/weirdness where they update some state (`count`), but then forget to make the `setContent` call to update the DOM. That's a very useful thing that React's `useState` does; a single way to update the state that is guaranteed to always be synced with the DOM. Of course, I could make a `setCount` function to help abstract this, but that's more boilerplate and just more opportunity for someone to screw it up.
Another point related to scoped components: one thing that I saw happen in jQuery codebases (and I think the same would happen here) is that it's too easy to mistakenly write a rogue selector that affects some part of the DOM that is far away from what was intended. It's one of those great power = great responsibility things... but I think this power more often leads to complex and confusing code that is hard for someone to understand and maintain.
React can be frustrating at times, when it seems like it would be easiest for a parent component to directly manipulate some nested child (or vice versa), but I think this friction often just leads to code that is easier to reason over.
- danielvaughn 2y ago"greater power & greater responsibility" is definitely the tradeoff I'm making. One of the tradeoffs I list in the readme is that you really need to think about the UI in a way that you don't with React. It's certainly more expedient to use React and let it handle the platform itself. On the other hand, you pay for that in a multitude of other ways - it's more than just a few frustrations here and there.