5 ms·

The best take I've been offered is that the problem with Hooks is that they are kind of a quasi object-oriented solution (more or less it is encapsulating state

The best take I've been offered is that the problem with Hooks is that they are kind of a quasi object-oriented solution (more or less it is encapsulating state with a setter/getter) shoe-horned into a quasi-functional render pipeline that demands functional purity at scale (lest your performance falls off a cliff from over-rendering or you end up with odd side effects). That disconnect is why hooks just don't feel right.

andix 4y ago
Isn’t the best of both worlds what you want? I do a lot of FP and OOP, and both worlds are not perfect. You want to mix them in a way you get the best out of both worlds.
- CharlieDigital 4y ago
  Each has a different mental model and as Evan You said, the host language itself is not suited for a "pure" FP approach and you end up with a leaky abstraction. As the article states, function closures are how classes are actually implemented in JavaScript so rather than mash the two together, it would seem a more cohesive mental model to simply use a class. If you step back and look at the broader landscape of UI across desktop (Windows, Mac, Linux), devices (iOS, Android), and web: how many libraries and toolkits are FP and how many are OOP in their abstraction when it comes to managing components and object instances?
  - Rapzid 4y ago
    > function closures are how classes are actually implemented in JavaScript Quite the opposite with V8.
  - andix 4y ago
    If you love OOP, then use Angular. It’s OOP all the way! But you will probably regret using it… There are also a lot of UI frameworks that are completely functional. Take your pick. (ReScript would be the most obvious choice for a react developer) But for a good reason the hybrid FP/OOP framework React on JS/TS is one of the most popular.
    - CharlieDigital 4y ago
      Even Solid and Preact are OOP in nature since JS closures are how classes are represented in JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Classes are in fact "special functions", and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declaration. The difference is that React functional components are effectively "parroting" FP and half-in (stateless components) and half-out (hooks). Solid, Preact, Vue are all-out.
      - andix 4y ago
        By that logic F# is also not an functional language, because it gets compiled to CLR classes. For me those implementation details are not important. But sure, you’re right.
        CharlieDigital 4y ago
        F# is not a functional language. Even says so in the docs: https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ F# has full support for programming with objects in .NET, including classes, interfaces, access modifiers, abstract classes, and so on. For more complicated functional code, such as functions that must be context-aware, objects can easily encapsulate contextual information in ways that functions cannot. https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/classes https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... Classes represent the fundamental description of .NET object types; the class is the primary type concept that supports object-oriented programming in F#. https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsha... F# has full support for objects, which are useful when you need to blend data and functionality. The underlying CIL representation of a lambda expression is an object; the functional side of .NET (whether C# or F#) is syntactic sugar on top of an OOP runtime. (C#/.NET dev by day dabbling in F#)
        4y ago
bayesian_horse 4y ago
Hooks are often side effects (but not always) and that sounds like "imperative" programming, but actually the side effect is what is inside the useEffect hook, not so much the hook itself. The component is still a pure function. It "returns" side effects without executing them, just not as the function return value but through a side channel. But that side channel is sort of a clutch to achieve a pure relation from input to output, just that the output is now a return value from the function plus the sideeffects, which may be executed or not.
- CharlieDigital 4y ago
  "Side effect" in my comment means an unintended side effect from an impure functional component (often a case of missing a useEffect, useMemo, or useCallback).
  - bayesian_horse 4y ago
    "Side Effect" in functional programming usually means the function is affecting something other than the output. And calling a hooks really doesn't, they just output the description of such an effect on a side channel.
    - CharlieDigital 4y ago
      > usually means the function is affecting something other than the output That's exactly the point. If you leave an errant function call in a functional component, it's going to affect something other than the output of that component.

andix 4y ago

Isn’t the best of both worlds what you want? I do a lot of FP and OOP, and both worlds are not perfect. You want to mix them in a way you get the best out of both worlds.

CharlieDigital 4y ago
Each has a different mental model and as Evan You said, the host language itself is not suited for a "pure" FP approach and you end up with a leaky abstraction. As the article states, function closures are how classes are actually implemented in JavaScript so rather than mash the two together, it would seem a more cohesive mental model to simply use a class. If you step back and look at the broader landscape of UI across desktop (Windows, Mac, Linux), devices (iOS, Android), and web: how many libraries and toolkits are FP and how many are OOP in their abstraction when it comes to managing components and object instances?
- Rapzid 4y ago
  > function closures are how classes are actually implemented in JavaScript Quite the opposite with V8.
- andix 4y ago
  If you love OOP, then use Angular. It’s OOP all the way! But you will probably regret using it… There are also a lot of UI frameworks that are completely functional. Take your pick. (ReScript would be the most obvious choice for a react developer) But for a good reason the hybrid FP/OOP framework React on JS/TS is one of the most popular.
  - CharlieDigital 4y ago
    Even Solid and Preact are OOP in nature since JS closures are how classes are represented in JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Classes are in fact "special functions", and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declaration. The difference is that React functional components are effectively "parroting" FP and half-in (stateless components) and half-out (hooks). Solid, Preact, Vue are all-out.
    - andix 4y ago
      By that logic F# is also not an functional language, because it gets compiled to CLR classes. For me those implementation details are not important. But sure, you’re right.
      - CharlieDigital 4y ago
        F# is not a functional language. Even says so in the docs: https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ F# has full support for programming with objects in .NET, including classes, interfaces, access modifiers, abstract classes, and so on. For more complicated functional code, such as functions that must be context-aware, objects can easily encapsulate contextual information in ways that functions cannot. https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/classes https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... Classes represent the fundamental description of .NET object types; the class is the primary type concept that supports object-oriented programming in F#. https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsha... F# has full support for objects, which are useful when you need to blend data and functionality. The underlying CIL representation of a lambda expression is an object; the functional side of .NET (whether C# or F#) is syntactic sugar on top of an OOP runtime. (C#/.NET dev by day dabbling in F#)
        4y ago

bayesian_horse 4y ago

Hooks are often side effects (but not always) and that sounds like "imperative" programming, but actually the side effect is what is inside the useEffect hook, not so much the hook itself. The component is still a pure function. It "returns" side effects without executing them, just not as the function return value but through a side channel. But that side channel is sort of a clutch to achieve a pure relation from input to output, just that the output is now a return value from the function plus the sideeffects, which may be executed or not.

CharlieDigital 4y ago
"Side effect" in my comment means an unintended side effect from an impure functional component (often a case of missing a useEffect, useMemo, or useCallback).
- bayesian_horse 4y ago
  "Side Effect" in functional programming usually means the function is affecting something other than the output. And calling a hooks really doesn't, they just output the description of such an effect on a side channel.
  - CharlieDigital 4y ago
    > usually means the function is affecting something other than the output That's exactly the point. If you leave an errant function call in a functional component, it's going to affect something other than the output of that component.