8 ms·

React is nothing new - these patterns that are being used have been with us for decades. Sure you can go about programming without knowing these patterns, but l

React is nothing new - these patterns that are being used have been with us for decades. Sure you can go about programming without knowing these patterns, but looking for ways around in order to know and understand less is a dead end. If you can't understand what hooks, reducers or actions do, why not spending more time on it? Sooner or later a newbie will encounter more complex project and having themselves shielded from knowledge will likely cause them to give up.

gfxgirl 6y ago
Hooks IMO are a poor design. Calling a function that does something different with the same parameters is an anti-pattern. const [v, setV] = useState(123); First call v gets set to 123, second call it doesn't. WAT!
- nwienert 6y ago
  What? Functions can do anything, even outside of hooks you can have memoized functions. Algebraic Effects are the thing I'm most glad React introduced, hooks are nothing short of a revolution for UI.
  - eyelidlessness 6y ago
    Functions which return different data for the same input aren’t functions. It’s a bad interface.
    - Chernobog 6y ago
      That's a very general statement. I wouldn't accuse you of implying that it would also apply to e.g. Date.now(), but I firmly disagree that it applies to hooks. I get that hooks are declared in the form of functions, and that pure functions are the desired pattern in many cases. But I like to think of hooks as hooks, not functions (emphasized by the naming convention of prefixing with "use"). We are in the context of React, after all, and I think it is comparable to critique of JSX because of "separation of concerns". Yes, valid critique in many cases, but not necessarily applicable to React. Having been a React developer for over 5 years now, I think hooks solve a lot of problems that before would typically have been solved with Redux, Redux Saga and other libraries. Or with home made solutions, leading to various degrees of mess. From what I've seen, hooks have enabled React devs to write code that is even easier to understand, while also keeping things simpler and external libraries fewer.
      - nwienert 6y ago
        Yea, it's definitely a workaround for not having algebraic effects, you can basically think of it as a yield. Of course ideally the language would have it first class, it doesn't change the fact that they are immensely useful. Having composable stateful logic that always handles side-effects is incredibly useful, and it works really well within the immutable data / top down data flow model of React. I'd love to hear the alternatives, as I spent years researching and working on many (Redux and FRP/reactions) and they're simply not as nice.
      - eyelidlessness 6y ago
        > That's a very general statement. I wouldn't accuse you of implying that it would also apply to e.g. Date.now() You don’t need to, I’ll gladly go on record saying Date.now() is not a function. It’s a subroutine. The clearest signal isn’t even its return value, it’s the fact that it takes no input. > [... everything else you said ...] I don’t have a problem with the expressiveness of hooks, nor the general way they solve a problem by defining clear APIs for interacting with reactivity and state. I have a problem with the context in which they’re called, and the way they infect their context by changing the semantics to be sometimes else. Hooks are something you instantiate and use in your component’s lifecycle. If it were that simple, you could call them in an outer function and return a component. But because you call them while defining the component’s behavior, your component is no longer semantically a function of props, it’s a constructor. A better API would be hooks called in a component factory, returning components which use those hooks.
        Chernobog 6y ago
        Thank you for elaborating! I remember I was really curious when they introduced them, since there had been a lot of focus in the community on stateless functional components before, and the benefits of their purity. Now suddenly they were renamed to function components instead, and as you say, are no longer guaranteed to simply be a function of their props. I guess what we disagree on is whether that is an issue or not. What problems do you feel the current hooks API is causing, that could be solved with a different API?
- eyelidlessness 6y ago
  EXACTLY! This is mind boggling. And it’s such an easy thing to solve, by allowing components with hooks to return components that receive hooks data as props.
- varispeed 6y ago
  I agree with you that hooks are a menace and seem to have been introduced for the same reason - to make new developers think less. I think that backfired spectacularly, but that does not mean you should not learn it and also know why this is an anti-pattern. Unfortunately junior devs are very happy to jump on the hooks and then when you come in to fix the mess, it's just a poor show.
eyelidlessness 6y ago
The problem with understanding what hooks do is that they’re basically an involuntary red pill. React and other libraries supporting function components have either a compiler or runtime fiction that your view is a function of input. Hooks force the reconciliation logic into your view, and turn your “function” into a constructor. Sure, you can reason about it. But now you can’t reason about your language primitives.

gfxgirl 6y ago

Hooks IMO are a poor design. Calling a function that does something different with the same parameters is an anti-pattern. const [v, setV] = useState(123); First call v gets set to 123, second call it doesn't. WAT!

nwienert 6y ago
What? Functions can do anything, even outside of hooks you can have memoized functions. Algebraic Effects are the thing I'm most glad React introduced, hooks are nothing short of a revolution for UI.
- eyelidlessness 6y ago
  Functions which return different data for the same input aren’t functions. It’s a bad interface.
  - Chernobog 6y ago
    That's a very general statement. I wouldn't accuse you of implying that it would also apply to e.g. Date.now(), but I firmly disagree that it applies to hooks. I get that hooks are declared in the form of functions, and that pure functions are the desired pattern in many cases. But I like to think of hooks as hooks, not functions (emphasized by the naming convention of prefixing with "use"). We are in the context of React, after all, and I think it is comparable to critique of JSX because of "separation of concerns". Yes, valid critique in many cases, but not necessarily applicable to React. Having been a React developer for over 5 years now, I think hooks solve a lot of problems that before would typically have been solved with Redux, Redux Saga and other libraries. Or with home made solutions, leading to various degrees of mess. From what I've seen, hooks have enabled React devs to write code that is even easier to understand, while also keeping things simpler and external libraries fewer.
    - nwienert 6y ago
      Yea, it's definitely a workaround for not having algebraic effects, you can basically think of it as a yield. Of course ideally the language would have it first class, it doesn't change the fact that they are immensely useful. Having composable stateful logic that always handles side-effects is incredibly useful, and it works really well within the immutable data / top down data flow model of React. I'd love to hear the alternatives, as I spent years researching and working on many (Redux and FRP/reactions) and they're simply not as nice.
    - eyelidlessness 6y ago
      > That's a very general statement. I wouldn't accuse you of implying that it would also apply to e.g. Date.now() You don’t need to, I’ll gladly go on record saying Date.now() is not a function. It’s a subroutine. The clearest signal isn’t even its return value, it’s the fact that it takes no input. > [... everything else you said ...] I don’t have a problem with the expressiveness of hooks, nor the general way they solve a problem by defining clear APIs for interacting with reactivity and state. I have a problem with the context in which they’re called, and the way they infect their context by changing the semantics to be sometimes else. Hooks are something you instantiate and use in your component’s lifecycle. If it were that simple, you could call them in an outer function and return a component. But because you call them while defining the component’s behavior, your component is no longer semantically a function of props, it’s a constructor. A better API would be hooks called in a component factory, returning components which use those hooks.
      - Chernobog 6y ago
        Thank you for elaborating! I remember I was really curious when they introduced them, since there had been a lot of focus in the community on stateless functional components before, and the benefits of their purity. Now suddenly they were renamed to function components instead, and as you say, are no longer guaranteed to simply be a function of their props. I guess what we disagree on is whether that is an issue or not. What problems do you feel the current hooks API is causing, that could be solved with a different API?
eyelidlessness 6y ago
EXACTLY! This is mind boggling. And it’s such an easy thing to solve, by allowing components with hooks to return components that receive hooks data as props.
varispeed 6y ago
I agree with you that hooks are a menace and seem to have been introduced for the same reason - to make new developers think less. I think that backfired spectacularly, but that does not mean you should not learn it and also know why this is an anti-pattern. Unfortunately junior devs are very happy to jump on the hooks and then when you come in to fix the mess, it's just a poor show.

eyelidlessness 6y ago

The problem with understanding what hooks do is that they’re basically an involuntary red pill. React and other libraries supporting function components have either a compiler or runtime fiction that your view is a function of input. Hooks force the reconciliation logic into your view, and turn your “function” into a constructor. Sure, you can reason about it. But now you can’t reason about your language primitives.