3 ms·

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 e

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.

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.