> Pure functions: Functional programs are constructed using only pure functions, meaning functions that have no side effects. A function has a side effect if it does anything other than simply return a result. For example, modifying global state, printing a message to the console, and mutating the DOM are all side effects.
This really makes it sound like functional programming cannot accomplish much of value.
Can't do I/O? Can't do UI? Is functional programming just for computation then? How many people even work in software that only does pure computation anymore? What good is pure computation if you can't even write it to a terminal after, because "No I/O"
This seems silly. Surely functional programming must have a broader definition than this.
Yeah, I’m not entirely sure what the point of the original article is. We know the parts that aren’t functional (hooks, I/O). Hell, the Component itself can be wrapped in a memoizer and become unfunctional all at once, left as a side effect of reconciliation.
The point of the FP concepts introduced to React is to lessen the cognitive load of the render cycle _of an individual component_. But I think the team is pretty clear about when side effects are part of patterning (literally one of the hooks is called “useEffect”).
Being explicit about effects does not make the function pure, does it? Why claim FP credentials if all or most of your functions are going to be impure?
I’m not sure the react team ever makes such a claim. Indeed, the only claim of strict FP I could find in the docs comes by way of this quote:
“ All React components must act like pure functions with respect to their props.”
Which they do. You cannot and must not mutate props. There are of course ways around this (JavaScript being JavaScript) by, say, passing a useRef defined constant down and then updating its “current” field, but that’s completely on you.
> I’m not sure the react team ever makes such a claim
How about this quote:
"Finally, if you’re a functional programming purist and feel uneasy about React relying on mutable state as an implementation detail, you might find it satisfactory that handling Hooks could be implemented in a pure way using algebraic effects (if JavaScript supported them)."
That sure sounds like they are saying even FP purists should feel comfortable using hooks.
8 comments
[ 3.2 ms ] story [ 30.8 ms ] threadThis really makes it sound like functional programming cannot accomplish much of value.
Can't do I/O? Can't do UI? Is functional programming just for computation then? How many people even work in software that only does pure computation anymore? What good is pure computation if you can't even write it to a terminal after, because "No I/O"
This seems silly. Surely functional programming must have a broader definition than this.
https://www.reddit.com/r/javascript/comments/nnu7vf/why_reac...
The point of the FP concepts introduced to React is to lessen the cognitive load of the render cycle _of an individual component_. But I think the team is pretty clear about when side effects are part of patterning (literally one of the hooks is called “useEffect”).
“ All React components must act like pure functions with respect to their props.”
Which they do. You cannot and must not mutate props. There are of course ways around this (JavaScript being JavaScript) by, say, passing a useRef defined constant down and then updating its “current” field, but that’s completely on you.
How about this quote:
"Finally, if you’re a functional programming purist and feel uneasy about React relying on mutable state as an implementation detail, you might find it satisfactory that handling Hooks could be implemented in a pure way using algebraic effects (if JavaScript supported them)."
That sure sounds like they are saying even FP purists should feel comfortable using hooks.
See https://medium.com/@dan_abramov/making-sense-of-react-hooks-...