React is pretty nice overall, just why do we design things to be so unintuitive. Dark patterns.
Which is a huge win IMO because the whole class/object paradigm in JavaScript is broken, and tracking what ‘this’ might be is literally impossible.
I think that’s sufficient reason to use hooks.
Hooks bring a completely new paradigm and I think it was brought out of Beta too early, so React now has to stick with certain concepts that appear bad ideas in hindsight (a fairly simple and relevant example would be that running useEffect on every render should not have been the default…I suspect the React team could have swapped the behaviors for empty array dependency and no dependency parameter, and it wouldn’t be any more logically weird than what we have today and the default behavior would have been far less footgun-ny).
I do think the general idea behind hooks is excellent. I think some of the existing choices, however, need a significant rethink, with the additional real world experience the React devs have with it now.
I chuckled. `this` is a piece of cake to understand compared to hooks.
`this` is a function argument that is typically passed to the function by placing it left of the dot at the time when you call the function. That's all you need to know - now you understand `this`.
Hooks are a whole nightmare in comparison - there is a stateful counter that assigns an index to every `useState` call just to determine which result you need to get back. This is a terribly error-prone design that passed review with lots of dubious justifications.
And if they really wanna go there, it was the React team itself that took away method auto-binding when they forced everyone to use `class` keyword. Mixins were already available in `createClass`, and if they wanted privacy between mixins, that's totally do-able with Symbols.
myStringNumbers.map(parseInt)
Very tangentially related, Apple's Metal API has a function that copies a texture. You pass it a width, height, etc... But, if the texture is compressed, then 255 of 256 possible value combos you pass it will be invalid since compressed textures can only be copied in block multiples. I think it would have been a better designed function if it only took width and height in blocks instead of pixels (with uncompressed textures defined has having 1x1 pixel blocks). Then this nonsense of 255 of 256 values being bad would disappear. There's a ton of other inconsistencies in that function. For example, you pass it destinationBytesPerRow when copying to a buffer but if the texture is compressed you pass it say 40 rows and it will only only actually copy 10 rows of blocks and only advance the destination every 4 rows instead of every row. It's arguably a poorly designed function. Thought, I suspect it was inspired by similarly poorly designed functions in other graphics APIs
Just use an arrow function to wrap the callbackFn.
https://docs.python.org/3/library/functions.html#enumerate
https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...
https://docs.julialang.org/en/v1/base/iterators/#Base.Iterat...
Amusingly in Haskell it only takes nine characters to define enumerate, so there’s not much benefit giving it a name!
enumerate = zip [0..]
I think a big part of the problem is we need to stop selling useEffect as a replacement for the lifecycle methods of class based components. It also probably would've been a lot less confusing if we called it something like useSideEffect
I think any react linting setup resolves most of the confusion but there's a lot of people that start off and don't even know how to set up lint rules for react. They should be a default in any react app imo
The part I don't like about useEffect is that developers tend to overuse it and when they get stuck in infinite render loops you can see the whole mess it can lead to and how hard it can be to untangle monkey patched logic.
I’d say its the opposite; people who used lifecycle methods know that useEffect and friends eliminates an entire class of bugs. People who started with hooks dont understand the problems it solved, and only see the quirks
You could have this API
this.addListener('mount', () => {
// do things on mount
// return cleanup to be called on unmount
return () => cleanup()
})
But no, the syntax wasn't "clean" (you'd pass `this` as an argument to the "custom hooks" equivalent"), so instead we got this error-prone order-dependent design that doesn't allow conditional execution and runs on every render.
It makes perfect sense from inside of useEffect.
If there are no dependencies ([]), the dependencies can never change, so React can always reuse the old effect.
If the dependencies aren’t defined, there’s no way to tell if the old effect is OK, so React must always rebuild it.
**
But `useEffect(()=>{})` doesn’t explicitly show that React will get `dependencies = undefined`, and in this case that’s unusually important.
You could have ESlint force you to change that to `useEffect(()=>{}, undefined)`, I suppose…
For useEffect, exhaustive-hooks & Typescript say nothing, because a non-memoised Effect is a reasonable thing to write. It’s just not a great thing to write accidentally.