4 ms·

> weird step into "magic" for a library that has been a pretty damn thin layer on top of JS I mean, hooks are totally this. They fundamentally break the concep

> weird step into "magic" for a library that has been a pretty damn thin layer on top of JS I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state (i.e. magic). The best way I can describe it is a cousin of dynamic scoping from the bad old LISP days. Back before lexical scoping was invented. So you end up with all these caveats and gotchas. Go look up useRef with useEffect and useCallback. It's all a total clusterfuck. The lifecycle methods weren't perfect. But at least you could understand them. But I lost a lot of respect for React way back when they started fussing with the lifecycle API, a year or two before hooks. Their vDOM abstraction was starting to leak heavily and they were struggling to make sense of it. When people say they like React, I really suspect they mean they like JSX. React, itself, is a mess. Always has been.

ironmagma 5y ago
They’re called “function components,” not “functional”, because they reside within a JS `function` as opposed to a class. The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects. The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.
- dragonwriter 5y ago
  > It’s much easier to create a list of dependencies a la second argument to useEffect. Even easier to just not do that, either, as in Solid’s version of hooks.
  - ironmagma 5y ago
    Honest question, is what you’re referring to this[1] or something else? I’d be interested to see how hooks could work without side effects. [1] https://github.com/ryansolid/component-register-hooks https://github.com/ryansolid/component-register-hooks
    - dragonwriter 5y ago
      > Honest question, is what you’re referring to this[1] or something else? I’m talking about Solid, the web framework, which has hooks (they call them “effects”) similar to those in React, but which do not require explicit dependency lists when specifying them. https://www.solidjs.com/tutorial/introduction_effects https://www.solidjs.com/tutorial/introduction_effects
      - ironmagma 5y ago
        Thanks. I don't understand how it's better though, wouldn't you need to start following the Rules of Hooks for this data retrieval (`count()`) as well, lest the renderer not know what all your dependencies are?
- deckard1 5y ago
  > They’re called “function components,” not “functional” They've been calling them functional components forever. https://github.com/facebook/react/blob/main/packages/react/index.js#L11 https://github.com/facebook/react/blob/main/packages/react/i... I'm not sure why you're being a language nazi here. It's beside the points I was making anyway. > The word you’re looking for is side effect. Enough with your patronizing. Obviously it is using side-effects. That's the entire point I was making. Functions (as in the term from "functional programming") do not produce side-effects. Functions do not contain state. You know what is good at containing state? Objects. The whole paradigm of an "object" is exactly what React is trying to do with functions. It's nonsense. You can't call a hook function outside of React's apparatus. When React calls one of these hook functions, it has to dynamically switch out the context. Which is where my analogy to dynamic scoping comes from. > an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function Yes, well, as I said React has always been a mess and there are just as many problems with useEffect. Throwing out the entire API is just dumb. Libraries are no longer universal. You have to consider whether it's using hooks or not. Especially since they never formally deprecated lifecycle methods. They just shrugged their shoulders and went "here's hooks, use them if you like them."
  - ironmagma 5y ago
    `StatelessFunctionalComponent` is not something that's publicly exported, at least from `"react"`. The convention is to use the `React.FunctionComponent`, or `React.FC` annotation. > Functions (as in the term from "functional programming") do not produce side-effects. This isn't true, even in the so-called "functional languages." Calling a function in Clojure could produce side effects, and the same is true in Haskell. In Haskell, calling a function that produces a side effect would necessarily return an IO monad, but that's a separate concern from whether the function invocation caused the side effect. > Libraries are no longer universal. You have to consider whether it's using hooks or not. You almost never have to think about this. Either a library provides hooks or it provides components. If it provides components, they could be implemented using the old component-style API or using function components; I have no idea, and it's irrelevant unless I plan to fork the library. Conversely if the library provides only a hook, I can easily wrap it in a thin component layer if that's the interface I prefer. The libraries are therefore effectively universal, since there's nothing that says I can't use a hook-based component within a function component, or vice-versa.
nawgz 5y ago
> I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state State and React have always been fundamentally intertwined, so I'm going to heavily disagree with the claim that hooks are a new magic wrt React. Personally, as someone who has used React for a long time, hooks have been a very intuitive and terse new syntax to use the lifecycle hooks & provides a far superior way to deal with state machine transitions. > Go look up useRef with useEffect and useCallback I must say, as a pro web developer who has built loads of applications, including model editors, charts with React views on top of D3 math, interactive 3D renderings, graphs, you name it, I don't know why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. What use case are you trying to solve that requires those hooks and what issue with those hooks exists that is blocking you? > I really suspect they mean they like JSX. React, itself, is a mess. Always has been Oh, you just hated React all along, so you probably never understood it. Easy to see why you don't like it then.
- deckard1 5y ago
  > why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. > Oh, you just hated React all along, so you probably never understood it. Sure, asshole. I've only been using React for 6 years now. But whatever.
  - nawgz 5y ago
    > The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. Or that you are doing questionable things with it? My guess from your tone and general confusion around React is that you expect useRef to have lifecycle hooks when the `current` value changing does not have any lifecycle hooks at all, and somehow your problem with that has made you rail against these hooks. Feel free to enlighten me - I have useRef and useEffect all over my codebases, I have never used useCallback though > Sure, asshole. I've only been using React for 6 years now Your own words: "React, itself, is a mess. Always has been". That's a comical statement to make if you're not emotionally biased against a library. Especially when that library is well-organized, with strong lifecycle guarantees, and gives you the strongest out-of-the-box composability of any comparable web framework. But no, it's you that's right, React sucks and doesn't work, it's the top JS library because JS developers are idiots right? Edit: it additionally appears you downvoted my entire thread contribution, so I'm going to take it as you don't understand the point of useRef at all. :)
steve_adams_86 5y ago
I think this is a case of to each their own. I find hooks provide a far more declarative, testable, predictable developer experience. The simplicity of useEffect, useCallback, useRef, etc. makes it so I know exactly what I need to reach for when I need to accomplish certain things. It can get complex, but I find that usually means you need to back off and rethink things.

ironmagma 5y ago

They’re called “function components,” not “functional”, because they reside within a JS `function` as opposed to a class. The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects. The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.

dragonwriter 5y ago
> It’s much easier to create a list of dependencies a la second argument to useEffect. Even easier to just not do that, either, as in Solid’s version of hooks.
- ironmagma 5y ago
  Honest question, is what you’re referring to this[1] or something else? I’d be interested to see how hooks could work without side effects. [1] https://github.com/ryansolid/component-register-hooks https://github.com/ryansolid/component-register-hooks
  - dragonwriter 5y ago
    > Honest question, is what you’re referring to this[1] or something else? I’m talking about Solid, the web framework, which has hooks (they call them “effects”) similar to those in React, but which do not require explicit dependency lists when specifying them. https://www.solidjs.com/tutorial/introduction_effects https://www.solidjs.com/tutorial/introduction_effects
    - ironmagma 5y ago
      Thanks. I don't understand how it's better though, wouldn't you need to start following the Rules of Hooks for this data retrieval (`count()`) as well, lest the renderer not know what all your dependencies are?
deckard1 5y ago
> They’re called “function components,” not “functional” They've been calling them functional components forever. https://github.com/facebook/react/blob/main/packages/react/index.js#L11 https://github.com/facebook/react/blob/main/packages/react/i... I'm not sure why you're being a language nazi here. It's beside the points I was making anyway. > The word you’re looking for is side effect. Enough with your patronizing. Obviously it is using side-effects. That's the entire point I was making. Functions (as in the term from "functional programming") do not produce side-effects. Functions do not contain state. You know what is good at containing state? Objects. The whole paradigm of an "object" is exactly what React is trying to do with functions. It's nonsense. You can't call a hook function outside of React's apparatus. When React calls one of these hook functions, it has to dynamically switch out the context. Which is where my analogy to dynamic scoping comes from. > an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function Yes, well, as I said React has always been a mess and there are just as many problems with useEffect. Throwing out the entire API is just dumb. Libraries are no longer universal. You have to consider whether it's using hooks or not. Especially since they never formally deprecated lifecycle methods. They just shrugged their shoulders and went "here's hooks, use them if you like them."
- ironmagma 5y ago
  `StatelessFunctionalComponent` is not something that's publicly exported, at least from `"react"`. The convention is to use the `React.FunctionComponent`, or `React.FC` annotation. > Functions (as in the term from "functional programming") do not produce side-effects. This isn't true, even in the so-called "functional languages." Calling a function in Clojure could produce side effects, and the same is true in Haskell. In Haskell, calling a function that produces a side effect would necessarily return an IO monad, but that's a separate concern from whether the function invocation caused the side effect. > Libraries are no longer universal. You have to consider whether it's using hooks or not. You almost never have to think about this. Either a library provides hooks or it provides components. If it provides components, they could be implemented using the old component-style API or using function components; I have no idea, and it's irrelevant unless I plan to fork the library. Conversely if the library provides only a hook, I can easily wrap it in a thin component layer if that's the interface I prefer. The libraries are therefore effectively universal, since there's nothing that says I can't use a hook-based component within a function component, or vice-versa.

nawgz 5y ago

> I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state State and React have always been fundamentally intertwined, so I'm going to heavily disagree with the claim that hooks are a new magic wrt React. Personally, as someone who has used React for a long time, hooks have been a very intuitive and terse new syntax to use the lifecycle hooks & provides a far superior way to deal with state machine transitions. > Go look up useRef with useEffect and useCallback I must say, as a pro web developer who has built loads of applications, including model editors, charts with React views on top of D3 math, interactive 3D renderings, graphs, you name it, I don't know why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. What use case are you trying to solve that requires those hooks and what issue with those hooks exists that is blocking you? > I really suspect they mean they like JSX. React, itself, is a mess. Always has been Oh, you just hated React all along, so you probably never understood it. Easy to see why you don't like it then.

deckard1 5y ago
> why I would have anything to do with "useRef with useEffect and useCallback". I've never encountered any issue with these things. The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. > Oh, you just hated React all along, so you probably never understood it. Sure, asshole. I've only been using React for 6 years now. But whatever.
- nawgz 5y ago
  > The fact that you are asking and haven't hit the issue suggests you haven't actually used useRef before. Or that you are doing questionable things with it? My guess from your tone and general confusion around React is that you expect useRef to have lifecycle hooks when the `current` value changing does not have any lifecycle hooks at all, and somehow your problem with that has made you rail against these hooks. Feel free to enlighten me - I have useRef and useEffect all over my codebases, I have never used useCallback though > Sure, asshole. I've only been using React for 6 years now Your own words: "React, itself, is a mess. Always has been". That's a comical statement to make if you're not emotionally biased against a library. Especially when that library is well-organized, with strong lifecycle guarantees, and gives you the strongest out-of-the-box composability of any comparable web framework. But no, it's you that's right, React sucks and doesn't work, it's the top JS library because JS developers are idiots right? Edit: it additionally appears you downvoted my entire thread contribution, so I'm going to take it as you don't understand the point of useRef at all. :)

steve_adams_86 5y ago

I think this is a case of to each their own. I find hooks provide a far more declarative, testable, predictable developer experience. The simplicity of useEffect, useCallback, useRef, etc. makes it so I know exactly what I need to reach for when I need to accomplish certain things. It can get complex, but I find that usually means you need to back off and rethink things.