3 ms·

Don't call this functional programming. If you call setCount() then this is not functional because your function is doing something besides returning a value. I

Don't call this functional programming. If you call setCount() then this is not functional because your function is doing something besides returning a value. In fact, it is setting state, which is against FP principles.

jameshart 4y ago
Okay. But is it against FP principles to write software that runs in web browsers then? Because web browsers exist, and they work in a nonfunctional way. So to interact with one we need to do a little bit of imperative code. And then react lets us figure out what to do when the web browser responds to that imperative code by letting us run a largely functional program. Which is pretty neat considering we’re doing so in JavaScript. The thing that we’re after here is not a badge that we can slap on our code saying ‘certified 100% functional’. We are trying to write code using patterns that help us reason about and structure what we want the computer to do, avoid bugs, and ship software. If react managed to squeeze a surprisingly functional pattern into a JavaScript library to that end, can’t we just applaud the audacity and enjoy using it, without nitpicking that they didn’t actually reimplement the lambda calculus?
- petilon 4y ago
  Why is it necessary to use FP to write software that runs in web browsers? To be sure, FP has benefits (such as, it is much more straightforward to reason about FP code), but those benefits are not applicable in React. So why pretend it is FP? React is neither FP nor OOP. More on that here: https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...
- zelphirkalt 4y ago
  Web browsers are agnostic to the programming paradigms employed to code websites in. We might need to bend JS a lot to get FP though. JS has some quite procedural roots/basics. For example the timer API (setTimeout and so on).
ojkelly 4y ago
Most of the ideas at play here come from the functional programming world, which is why it’s often viewed from that lense. React builds on functional reactive programming, something the FP world is known for[0]. I’m not saying it’s pure FP in the dogmatic sense, I just wanted to point out it’s closer to FP than the other paradigms. Without the ability to interact with the outside world (side-effects), FP is not of much practical use. Not to say it’s bad or shouldn’t exist, just we need to add to it a bit to make it useful. Why would we do that? Because the underlying ideas and principles provide a great foundation. Building on that to get FRP and algebraic effects, monads and so on, is very different to starting from OOP and brining FP ideas over. React hooks are an interesting and tricky thing to put in a box, because they’re almost monads, almost thunks, almost algebraic effects. The interplay with fibers and components makes them hard to pin down, but they are much closer to functional than any other paradigm. [0] https://wiki.haskell.org/Functional_Reactive_Programming https://wiki.haskell.org/Functional_Reactive_Programming
- zelphirkalt 4y ago
  The web is (was) a pretty good example of something akin to FP: REST means all state is transferred with the response and then the whole thing is rendered in the browser. And then there is HTTP, so if you want a new page, you simple call another URL (like a function call). OK this is glossing over some parts like that cookies are also send, but they are additional optional arguments of that request (function call). That's what the mean (or meant, since the term is now muddied), when they say the connection is stateless. What we have with badly written React apps now (90% approx.) is a UI, that is not at all behaving like a typical website and very far from being like FP. We often cannot simply go back with the back button and expect to see the same page rendered. I mean we can, but the websites will fart in our face, if we do. We do not get the ability to simple send a link to someone and have them see the exact same page. It is a huge departure from anything FP. Furthermore from the dev perspective components feel more mainstream OOP than FP, since they store internal state and update it, which indirectly causes things I described above. Not sure where people see the FP. Not sure they really have done any FP language before or tried in projects to strictly adhere to FP principles, because that looks a lot differently than React components and mixing state, layout and styling in JSX/TSX.
agumonkey 4y ago
I don't know react details but set<X> are not effecting directly, it's just another iteration from prev -> next state (with the values given in set<X> hooks) which is functional.
epgui 4y ago
I believe higher-order functions and callbacks are completely ok in FP, no?

jameshart 4y ago

Okay. But is it against FP principles to write software that runs in web browsers then? Because web browsers exist, and they work in a nonfunctional way. So to interact with one we need to do a little bit of imperative code. And then react lets us figure out what to do when the web browser responds to that imperative code by letting us run a largely functional program. Which is pretty neat considering we’re doing so in JavaScript. The thing that we’re after here is not a badge that we can slap on our code saying ‘certified 100% functional’. We are trying to write code using patterns that help us reason about and structure what we want the computer to do, avoid bugs, and ship software. If react managed to squeeze a surprisingly functional pattern into a JavaScript library to that end, can’t we just applaud the audacity and enjoy using it, without nitpicking that they didn’t actually reimplement the lambda calculus?

petilon 4y ago
Why is it necessary to use FP to write software that runs in web browsers? To be sure, FP has benefits (such as, it is much more straightforward to reason about FP code), but those benefits are not applicable in React. So why pretend it is FP? React is neither FP nor OOP. More on that here: https://medium.com/codex/can-we-all-just-admit-react-hooks-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...
zelphirkalt 4y ago
Web browsers are agnostic to the programming paradigms employed to code websites in. We might need to bend JS a lot to get FP though. JS has some quite procedural roots/basics. For example the timer API (setTimeout and so on).

ojkelly 4y ago

Most of the ideas at play here come from the functional programming world, which is why it’s often viewed from that lense. React builds on functional reactive programming, something the FP world is known for[0]. I’m not saying it’s pure FP in the dogmatic sense, I just wanted to point out it’s closer to FP than the other paradigms. Without the ability to interact with the outside world (side-effects), FP is not of much practical use. Not to say it’s bad or shouldn’t exist, just we need to add to it a bit to make it useful. Why would we do that? Because the underlying ideas and principles provide a great foundation. Building on that to get FRP and algebraic effects, monads and so on, is very different to starting from OOP and brining FP ideas over. React hooks are an interesting and tricky thing to put in a box, because they’re almost monads, almost thunks, almost algebraic effects. The interplay with fibers and components makes them hard to pin down, but they are much closer to functional than any other paradigm. [0] https://wiki.haskell.org/Functional_Reactive_Programming https://wiki.haskell.org/Functional_Reactive_Programming

zelphirkalt 4y ago
The web is (was) a pretty good example of something akin to FP: REST means all state is transferred with the response and then the whole thing is rendered in the browser. And then there is HTTP, so if you want a new page, you simple call another URL (like a function call). OK this is glossing over some parts like that cookies are also send, but they are additional optional arguments of that request (function call). That's what the mean (or meant, since the term is now muddied), when they say the connection is stateless. What we have with badly written React apps now (90% approx.) is a UI, that is not at all behaving like a typical website and very far from being like FP. We often cannot simply go back with the back button and expect to see the same page rendered. I mean we can, but the websites will fart in our face, if we do. We do not get the ability to simple send a link to someone and have them see the exact same page. It is a huge departure from anything FP. Furthermore from the dev perspective components feel more mainstream OOP than FP, since they store internal state and update it, which indirectly causes things I described above. Not sure where people see the FP. Not sure they really have done any FP language before or tried in projects to strictly adhere to FP principles, because that looks a lot differently than React components and mixing state, layout and styling in JSX/TSX.

agumonkey 4y ago

I don't know react details but set<X> are not effecting directly, it's just another iteration from prev -> next state (with the values given in set<X> hooks) which is functional.

epgui 4y ago

I believe higher-order functions and callbacks are completely ok in FP, no?