4 ms·

I haven't used React and React hooks as long as I have used Java and Maven, but consider this: If many successful people voluntarily use something you cannot u

I haven't used React and React hooks as long as I have used Java and Maven, but consider this: If many successful people voluntarily use something you cannot understand there is always the possibility that you are the one who are missing out on something. (FWIW: I've been there myself)

sbergot 6y ago
I have used them on a medium project. I enjoy them very much but I have seen a lot of people struggle with the "rules of hooks"* I can see why some people prefer to use classes where the design is cleaner (even though you are more limited). *: https://reactjs.org/docs/hooks-rules.html#:~:text=Only%20Call%20Hooks%20at%20the%20Top%20Level&text=Instead%2C%20always%20use%20Hooks%20at,multiple%20useState%20and%20useEffect%20calls https://reactjs.org/docs/hooks-rules.html#:~:text=Only%20Cal....
- presentation 6y ago
  If you use a linter though you can just auto enforce all the rules and back to it being just fine. An extra setup step but tools like create react app bundle ESLint for you already so I don’t mind it.
yeneek 6y ago
A lot of successful people use Cobol too
- eitland 6y ago
  Yep, but not voluntarily on greenfield projects unless I'm missing out on the latest trends from the Valley ;-)
  - yeneek 6y ago
    Fair enough. Still "successful people use it, so it must be good" isn't a valid argument for me.
BreakfastB0b 6y ago
I absolutely acknowledge this is a possibility, but I think I do understand why people use it. Because they're easy, hooks are just so god damn easy to use. Want some state? Just chuck in a `useState` and call it day. But the problem is, they're not simple, and that complexity will grow and grow until it makes the app unmaintainable. I've seen this happen at three different companies I've worked at.
- xwdv 6y ago
  One thing you are missing is a lot of organizations don’t care about UI tests. They’re brittle and the UI is always changing anyways so you get diminishing returns from writing many of them. Usually an end to end test is enough. UI logic is usually not that complicated, if it doesn’t work you will know right away. Hooks are acceptable.
- nicoburns 6y ago
  To me the main benefit isn't that they're easy, it's that they're composable. They allow you to reuse "business logic" in multiple components. If it's getting too complex then that's presumably when you ought to be creating a custom hook which wraps up some of that complexity.
  - valenterry 6y ago
    I'm not familiar with react hooks, but when I read what you write, my immediate reaction is: we already have a way to reuse business logic. It's called functions. Define a function and use it, either a global static function or pass it down to the component if you want to mock it. Reading the react docs, I find this part interesting: > Hooks were designed with static typing in mind. Because they’re functions, they are easier to type correctly than patterns like higher-order components. Importantly, custom Hooks give you the power to constrain React API if you’d like to type them more strictly in some way. React gives you the primitives, but you can combine them in different ways than what we provide out of the box. (https://reactjs.org/docs/hooks-faq.html#do-hooks-work-with-static-typing https://reactjs.org/docs/hooks-faq.html#do-hooks-work-with-s...) Seems to me as if hooks try to fix the lack of a good programming language. These approaches usually go wrong eventually. Maybe it's time to ditch Javascript (and even Typescript) and use a proper language (purescript maybe?) so that all these things can be done with just functions.
dbbk 6y ago
I actually think the problem is a lack of critical thinking. When Hooks were announced by Dan Abramov, people were hailing him as a genius etc, that this was a panacea.

sbergot 6y ago

I have used them on a medium project. I enjoy them very much but I have seen a lot of people struggle with the "rules of hooks"* I can see why some people prefer to use classes where the design is cleaner (even though you are more limited). *: https://reactjs.org/docs/hooks-rules.html#:~:text=Only%20Call%20Hooks%20at%20the%20Top%20Level&text=Instead%2C%20always%20use%20Hooks%20at,multiple%20useState%20and%20useEffect%20calls https://reactjs.org/docs/hooks-rules.html#:~:text=Only%20Cal....

presentation 6y ago
If you use a linter though you can just auto enforce all the rules and back to it being just fine. An extra setup step but tools like create react app bundle ESLint for you already so I don’t mind it.

yeneek 6y ago

A lot of successful people use Cobol too

eitland 6y ago
Yep, but not voluntarily on greenfield projects unless I'm missing out on the latest trends from the Valley ;-)
- yeneek 6y ago
  Fair enough. Still "successful people use it, so it must be good" isn't a valid argument for me.

BreakfastB0b 6y ago

I absolutely acknowledge this is a possibility, but I think I do understand why people use it. Because they're easy, hooks are just so god damn easy to use. Want some state? Just chuck in a `useState` and call it day. But the problem is, they're not simple, and that complexity will grow and grow until it makes the app unmaintainable. I've seen this happen at three different companies I've worked at.

xwdv 6y ago
One thing you are missing is a lot of organizations don’t care about UI tests. They’re brittle and the UI is always changing anyways so you get diminishing returns from writing many of them. Usually an end to end test is enough. UI logic is usually not that complicated, if it doesn’t work you will know right away. Hooks are acceptable.
nicoburns 6y ago
To me the main benefit isn't that they're easy, it's that they're composable. They allow you to reuse "business logic" in multiple components. If it's getting too complex then that's presumably when you ought to be creating a custom hook which wraps up some of that complexity.
- valenterry 6y ago
  I'm not familiar with react hooks, but when I read what you write, my immediate reaction is: we already have a way to reuse business logic. It's called functions. Define a function and use it, either a global static function or pass it down to the component if you want to mock it. Reading the react docs, I find this part interesting: > Hooks were designed with static typing in mind. Because they’re functions, they are easier to type correctly than patterns like higher-order components. Importantly, custom Hooks give you the power to constrain React API if you’d like to type them more strictly in some way. React gives you the primitives, but you can combine them in different ways than what we provide out of the box. (https://reactjs.org/docs/hooks-faq.html#do-hooks-work-with-static-typing https://reactjs.org/docs/hooks-faq.html#do-hooks-work-with-s...) Seems to me as if hooks try to fix the lack of a good programming language. These approaches usually go wrong eventually. Maybe it's time to ditch Javascript (and even Typescript) and use a proper language (purescript maybe?) so that all these things can be done with just functions.

dbbk 6y ago

I actually think the problem is a lack of critical thinking. When Hooks were announced by Dan Abramov, people were hailing him as a genius etc, that this was a panacea.