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."
`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.
They've been calling them functional components forever. 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."