5 ms·

If you want to see really ugly code, read the docs about Higher Order Components [0]. Hooks are better for building component abstractions than HOCs. Code whic

If you want to see really ugly code, read the docs about Higher Order Components [0]. Hooks are better for building component abstractions than HOCs. Code which can hook into mount/unmount, can trigger re-renders via state updates, etc. Also, dependency arrays in useEffect and useCallback are better than this kinda stuff in shouldComponentUpdate lifecycle method: if (prevProps.commentId !== this.props.commentId) { return true; } return false; [0]: https://reactjs.org/docs/higher-order-components.html https://reactjs.org/docs/higher-order-components.html

debaserab2 5y ago
I find dependency arrays to be neither intuitive or easy to debug. When you're missing a parameter or use the wrong one React can emit some pretty weird side effects that are hard to track down back to the dependency array. I generally like shaping my components as functions first and use hooks because I have to in order to do this but definitely not because I find them easier to understand than component lifecycle methods (even if they may be less verbose). To me, hooks are the ugly part, writing component as a single function is the part that makes it worth it.
- jitl 5y ago
  Do you use the exhaustive-hooks ESLint rule? I think without it hooks are unusable in a team setting.
  - brundolf 5y ago
    It helps a lot, but it has gaps, because it reasons about syntax and not values. A complete solution is intractable without integrating this stuff at a language/type-system level (and I don't mean TypeScript; TypeScript can't represent hooks' relationships either).
- nightpool 5y ago
  The general advice is to write your hooks without dependency arrays first, and then only add dependency arrays once you know what your hook body looks like. I find that that generally makes them much easier to debug. Also, yes, the exhaustive-hooks ESlint rule is a life-saver.
nsonha 5y ago
> If you want to see really ugly code, read the docs about Higher Order Components Never found HOC ugly, it's a normal function, not a magic one that hooks into React internals. Anyone familiar with OOP also regcognizes it as adapter. I think people tend to confuses syntactical simplicity with conceptual simplicity. But even syntactically, I don't find hooks simple once we pass the toy code examples. > Hooks are better for building abstractions than HOCs HOCs are more explicit, they change the props signature of the component. So if you like magic, you'd prefer hooks. Hooks are not better abstraction, they are better building blocks because they compose more nicely. A good abstraction is something you can pass around and use liberally without knowing the inner working. You can pass a HOC around and put it in conditional etc. Can't do that with hook because the inner working prohibits that and you are required to know such caveats.
zaphirplane 5y ago
Wouldn’t a purecomponent do this comparison built in
- srcreigh 5y ago
  Yeah. The same type of thing needs to happen in componentDidUpdate for side effects (reload data from API) etc.

debaserab2 5y ago

I find dependency arrays to be neither intuitive or easy to debug. When you're missing a parameter or use the wrong one React can emit some pretty weird side effects that are hard to track down back to the dependency array. I generally like shaping my components as functions first and use hooks because I have to in order to do this but definitely not because I find them easier to understand than component lifecycle methods (even if they may be less verbose). To me, hooks are the ugly part, writing component as a single function is the part that makes it worth it.

jitl 5y ago
Do you use the exhaustive-hooks ESLint rule? I think without it hooks are unusable in a team setting.
- brundolf 5y ago
  It helps a lot, but it has gaps, because it reasons about syntax and not values. A complete solution is intractable without integrating this stuff at a language/type-system level (and I don't mean TypeScript; TypeScript can't represent hooks' relationships either).
nightpool 5y ago
The general advice is to write your hooks without dependency arrays first, and then only add dependency arrays once you know what your hook body looks like. I find that that generally makes them much easier to debug. Also, yes, the exhaustive-hooks ESlint rule is a life-saver.

nsonha 5y ago

> If you want to see really ugly code, read the docs about Higher Order Components Never found HOC ugly, it's a normal function, not a magic one that hooks into React internals. Anyone familiar with OOP also regcognizes it as adapter. I think people tend to confuses syntactical simplicity with conceptual simplicity. But even syntactically, I don't find hooks simple once we pass the toy code examples. > Hooks are better for building abstractions than HOCs HOCs are more explicit, they change the props signature of the component. So if you like magic, you'd prefer hooks. Hooks are not better abstraction, they are better building blocks because they compose more nicely. A good abstraction is something you can pass around and use liberally without knowing the inner working. You can pass a HOC around and put it in conditional etc. Can't do that with hook because the inner working prohibits that and you are required to know such caveats.

zaphirplane 5y ago

Wouldn’t a purecomponent do this comparison built in

srcreigh 5y ago
Yeah. The same type of thing needs to happen in componentDidUpdate for side effects (reload data from API) etc.