5 ms·

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. Wan

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.
  - timhwang21 6y ago
    One key difference between hooks and functions is that hooks tap into some hidden global component registry (I'm being handwavey here but this is more or less what happens). This allows side effects to be persisted and tracked between function calls. You can probably build all this infrastructure yourself without hooks and only with plain functions. It'll involve some global store and some subscription mechanism. You'll end up with something really similar to Redux.
    - valenterry 6y ago
      > You can probably build all this infrastructure yourself without hooks and only with plain functions It sounds to me that such a concept would be very useful in a lot of contexts, so instead of specializing it only to react hooks, it might be better to just be a standalone library. E.g., why not use the same technique in Angular? That way, developers don't have to learn framework-specific ways of doing things again and again but can reuse their knowledge. I think the fact that everyone is building their own thing is one of the reasons why many people have this notion of "need to learn a new framework every half a year". Backend technology seems to do better here, maybe because the pace is slower?
      - timhwang21 6y ago
        > it might be better to just be a standalone library See: https://github.com/reduxjs/redux https://github.com/reduxjs/redux, among others. The React ecosystem did exactly this for the past few years, but evidently it was decided that a more native approach like hooks were better.
        valenterry 6y ago
        I know redux, but I believe that there should be an even more low level library. Coming from the backend, I miss something like the effect system builtin in Haskell/Purescript or added as a library to languages like Scala (e.g. https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/) or Kotlin (e.g. https://arrow-kt.io/docs/effects/io/ https://arrow-kt.io/docs/effects/io/)

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.
- timhwang21 6y ago
  One key difference between hooks and functions is that hooks tap into some hidden global component registry (I'm being handwavey here but this is more or less what happens). This allows side effects to be persisted and tracked between function calls. You can probably build all this infrastructure yourself without hooks and only with plain functions. It'll involve some global store and some subscription mechanism. You'll end up with something really similar to Redux.
  - valenterry 6y ago
    > You can probably build all this infrastructure yourself without hooks and only with plain functions It sounds to me that such a concept would be very useful in a lot of contexts, so instead of specializing it only to react hooks, it might be better to just be a standalone library. E.g., why not use the same technique in Angular? That way, developers don't have to learn framework-specific ways of doing things again and again but can reuse their knowledge. I think the fact that everyone is building their own thing is one of the reasons why many people have this notion of "need to learn a new framework every half a year". Backend technology seems to do better here, maybe because the pace is slower?
    - timhwang21 6y ago
      > it might be better to just be a standalone library See: https://github.com/reduxjs/redux https://github.com/reduxjs/redux, among others. The React ecosystem did exactly this for the past few years, but evidently it was decided that a more native approach like hooks were better.
      - valenterry 6y ago
        I know redux, but I believe that there should be an even more low level library. Coming from the backend, I miss something like the effect system builtin in Haskell/Purescript or added as a library to languages like Scala (e.g. https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/) or Kotlin (e.g. https://arrow-kt.io/docs/effects/io/ https://arrow-kt.io/docs/effects/io/)