5 ms·

> Hooks ruined the framework imo. Confusing api (useState returning an array for example). It just returns a tuple. That's not confusing at all and it's a very

by kaoD 2y ago

> Hooks ruined the framework imo. Confusing api (useState returning an array for example). It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. If there's anything that can be considered complex and footgun-y in React it's useEffect because most of the time you shouldn't use it at all but it can be abused very easily and it kinda works even if you abuse it (but introduces a huge maintenance burden).

dartos 2y ago
> It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. A few things wrong with this. It does not return a tuple, it returns an array with 2 elements. You, as the react dev, need to just know that this is the case and that one is the value and the other is a set function. In most modern languages, tuples are common, yes. But not in JavaScript. React isn’t a python or go framework, it’s a JavaScript framework. Why doesn’t it act like almost everything else in js land and return an object with 2 named fields? Why place extra knowledge burden on the developer? It’s just poor api design Yes useEffect is also a huge complex pain point, but it just takes longer to type out why that is. Pretty much all the hooks are as almost nothing else in the JavaScript ecosystem acts like they do.
- xpl 2y ago
  > Why doesn’t it act like almost everything else in js land and return an object with 2 named fields The explanation is actually very simple: because in 100% of times you need to give those two fields custom names. It is easier and more concise with tuple: const [text, setText] = ... Than with object + renaming, which quickly gets clumsy when you have dozens of such lines in your component: const {value: text, setValue: setText} = ...
  - dartos 2y ago
    That’s not a good reason. Especially in our world where strong typing is something preferable. Fewer characters at the cost of clarity is poor api design. Implicitness is almost always worse than explicitness. Explicit !== clumsy And again, almost nothing else in the js ecosystem behaves like this. Especially at the time of the big hooks update to react. Also, again, it’s not a tuple. It’s an array with 2 elements. JavaScript does not have tuples or the semantics for interacting with them as such. You just need to know that there’s always going to be 2 elements. That extra knowledge burden is the hallmark of poor api design.
    - xpl 2y ago
      > Also, again, it’s not a tuple. It’s an array with 2 elements. JavaScript does not have tuples or the semantics for interacting with them as such Not true. In TypeScript, there are tuples — you can perfectly describe an array having 2 elements with different types, and even give names to them: type KVPairTuple = [key: string, value: number] We use it all the time for simple 2-element thingies. You can say JavaScript isn't TypeScript, but cmon, just everybody out there uses TypeScript, it is the basic norm nowadays. So we're really talking about TypeScript semantics here. Also, even JS uses tuples for its core APIs. Enter `Object.entries` and `Object.fromEntries` — they operate on kv-pairs in form of 2-element arrays. So your assertion that tuples are something alien to JS ecosystem isn't accurate simply because of that.
      - dartos 2y ago
        > Not true. In TypeScript… Not talking about typescript. Typescript wasn’t nearly as wide spread or as complete back then anyway. Facebook was still on flow. > they operate on kv-pairs in form of 2-element arrays. So… Not tuples… > So your assertion that tuples are something alien to JS ecosystem isn't accurate simply because of that. My words were “almost nothing else.” I’m sure someone somewhere uses the idea of tuples in their js code (implemented as arrays, ofc) but it’s extremely far from the norm. Also none of that refutes my point that it’s poor api design. Thanks for being pedantic tho.
        kaoD 2y ago
        > Not talking about typescript. TS is just encoding JS semantics into a type system. A function returning a fixed-size array in JS is effectively returning, semantically, a tuple. They're just not a different type unlike in other languages (for different reasons). JS arrays are not even arrays since they (1) are not contiguous and (2) do not require items to be of the same size (typed arrays are actual arrays though) except by their backing implementation (which uses js vals, but that's a property of the implementation, not the language). They're sparse vectors. But nobody cares about that technical distinction and we still call fixed-size arrays tuples and variable-size arrays arrays. You can even attach properties to them because arrays are not vectors, they are objects. Or can be, for that matter. The backing implementations are complex and very dynamic. JS was intentionally made this simple so it could have emergent semantics. Scheme-ish. > Typescript wasn’t nearly as wide spread or as complete back then anyway. Facebook was still on flow. It was when they introduced hooks.
- xpl 2y ago
  > Yes useEffect is also a huge complex pain point We have a rule of thumb in our projects: if you use useEffect directly in application code, it is a probable sign that something is wrong with your code, like you're working on a wrong level of abstraction. Almost every direct use of useEffect is better solved with some standard hook from a popular library (like react-use or whatever you like — there are plenty of them). Like, binding event listeners? useEventListener Network/async calls? useAsync timeouts/intervals? useInterval, useTimeout And etc. etc. useEffect is really a low-level building block for library code and we rarely use it directly, as it is unsafe and hides the original intent. Much like `new` and `delete` in C++ — you don't use it directly, there are smart pointers. Library hooks are your safe smart pointers over useEffect.

by kaoD 2y ago

dartos 2y ago

> It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. A few things wrong with this. It does not return a tuple, it returns an array with 2 elements. You, as the react dev, need to just know that this is the case and that one is the value and the other is a set function. In most modern languages, tuples are common, yes. But not in JavaScript. React isn’t a python or go framework, it’s a JavaScript framework. Why doesn’t it act like almost everything else in js land and return an object with 2 named fields? Why place extra knowledge burden on the developer? It’s just poor api design Yes useEffect is also a huge complex pain point, but it just takes longer to type out why that is. Pretty much all the hooks are as almost nothing else in the JavaScript ecosystem acts like they do.

xpl 2y ago
> Why doesn’t it act like almost everything else in js land and return an object with 2 named fields The explanation is actually very simple: because in 100% of times you need to give those two fields custom names. It is easier and more concise with tuple: const [text, setText] = ... Than with object + renaming, which quickly gets clumsy when you have dozens of such lines in your component: const {value: text, setValue: setText} = ...
- dartos 2y ago
  That’s not a good reason. Especially in our world where strong typing is something preferable. Fewer characters at the cost of clarity is poor api design. Implicitness is almost always worse than explicitness. Explicit !== clumsy And again, almost nothing else in the js ecosystem behaves like this. Especially at the time of the big hooks update to react. Also, again, it’s not a tuple. It’s an array with 2 elements. JavaScript does not have tuples or the semantics for interacting with them as such. You just need to know that there’s always going to be 2 elements. That extra knowledge burden is the hallmark of poor api design.
  - xpl 2y ago
    > Also, again, it’s not a tuple. It’s an array with 2 elements. JavaScript does not have tuples or the semantics for interacting with them as such Not true. In TypeScript, there are tuples — you can perfectly describe an array having 2 elements with different types, and even give names to them: type KVPairTuple = [key: string, value: number] We use it all the time for simple 2-element thingies. You can say JavaScript isn't TypeScript, but cmon, just everybody out there uses TypeScript, it is the basic norm nowadays. So we're really talking about TypeScript semantics here. Also, even JS uses tuples for its core APIs. Enter `Object.entries` and `Object.fromEntries` — they operate on kv-pairs in form of 2-element arrays. So your assertion that tuples are something alien to JS ecosystem isn't accurate simply because of that.
    - dartos 2y ago
      > Not true. In TypeScript… Not talking about typescript. Typescript wasn’t nearly as wide spread or as complete back then anyway. Facebook was still on flow. > they operate on kv-pairs in form of 2-element arrays. So… Not tuples… > So your assertion that tuples are something alien to JS ecosystem isn't accurate simply because of that. My words were “almost nothing else.” I’m sure someone somewhere uses the idea of tuples in their js code (implemented as arrays, ofc) but it’s extremely far from the norm. Also none of that refutes my point that it’s poor api design. Thanks for being pedantic tho.
      - kaoD 2y ago
        > Not talking about typescript. TS is just encoding JS semantics into a type system. A function returning a fixed-size array in JS is effectively returning, semantically, a tuple. They're just not a different type unlike in other languages (for different reasons). JS arrays are not even arrays since they (1) are not contiguous and (2) do not require items to be of the same size (typed arrays are actual arrays though) except by their backing implementation (which uses js vals, but that's a property of the implementation, not the language). They're sparse vectors. But nobody cares about that technical distinction and we still call fixed-size arrays tuples and variable-size arrays arrays. You can even attach properties to them because arrays are not vectors, they are objects. Or can be, for that matter. The backing implementations are complex and very dynamic. JS was intentionally made this simple so it could have emergent semantics. Scheme-ish. > Typescript wasn’t nearly as wide spread or as complete back then anyway. Facebook was still on flow. It was when they introduced hooks.
xpl 2y ago
> Yes useEffect is also a huge complex pain point We have a rule of thumb in our projects: if you use useEffect directly in application code, it is a probable sign that something is wrong with your code, like you're working on a wrong level of abstraction. Almost every direct use of useEffect is better solved with some standard hook from a popular library (like react-use or whatever you like — there are plenty of them). Like, binding event listeners? useEventListener Network/async calls? useAsync timeouts/intervals? useInterval, useTimeout And etc. etc. useEffect is really a low-level building block for library code and we rarely use it directly, as it is unsafe and hides the original intent. Much like `new` and `delete` in C++ — you don't use it directly, there are smart pointers. Library hooks are your safe smart pointers over useEffect.