When you compile your pure Haskell code the resulting machine code is imperative and effectful.
And during the compilation process the code is verified to comply with numerous constraints that permit the compiler to make some very specific and beneficial assumptions about the code.
React doesn't pretend to be functional.
I think here we have to differentiate between React and the React community. Now clearly React itself can't be responsible for the entire React ecosystem - but often the wording in the documentation or the statements by core members encourage certain notions in the community.
React's mental model is often oversimplified as view = fn(state) — which is clearly functional as it implies view generation from state through transformation by a pure function.
React actually doesn't work that way — there are two sources of state — props which is state as handed down from the owner component to the nested component and state which is "persisted and managed" by React on behalf of the component instance. So while components do generate the view they also can change state in the process - i.e. components are not enforced to be referentially transparent or in web terms idempotent. So React cannot grant the typical benefits or guarantees that a typical FP environment can.
React's reliance on immutability further feeds into the image of being functional.
Then there is the fact that the community often refers to Function Components as Functional Components.
So when it comes right down to it, one has to wonder how much of "hooks and stateful function components" actually had to do with necessary innovation or whether or not the whole "functional image" is about keeping React trendy within the web development community at large.
but "view framework" name is kind of already taken by another project.
React predates Vue by about a year and despite its name Vue doesn't get to monopolize an entire tool category by virtue of how its name sounds.
all you get from it is that "React is not a framework" then it's not the sentence that's wrong - it's your interpretation of the sentence.
@jpochtar@reactjs@angular I think React is a UI library. It’s possible that our definition of “UI” might be a bit broader than what people tend to consider “view layer”, but I also think it’s not a framework.
19:12 PM - 09 Aug 2018
but I also think it’s not a framework.
It's not my interpretation, it's an active image being defended by a large portion of the React community. A framework, due to inversion of control, exerts a significant amount of design pressure on the structure of the "client side architecture". Calling React a library is disavowing the influence that React has as evidenced by countless sources describing React as unopinionated. Just because React is less constraining than Angular does not imply that it is "unopinionated" — it's just a matter of degree — React is very much opinionated, just not as much as Angular.
It was needed because creating classes in ES5 is really awkward.
Did it return a constructor function? A factory function for component instances? At best it's bad naming because createComponent would have been more apt — at worst it's trendy naming because in 2013 "real programmers" used class-based object-orientation — not just plain functions and objects.
Generators are pure functions as long as you don't mutate state within them.
Most generators used in JavaScript are not pure. And JavaScript has no controlled runtime support for lazy evaluation, so lazy evaluation is emulated with mutable state inside the function's closure.
useState() serves the same purpose as State Monad.
"Purpose" perhaps but again without committing to any constraints. In order to preserve referential transparency functions operating within a state monad have a signature of (state) => [state, result]. React function components could have easily adopted a similar signature. One benefit would have been that it would be trivial to micro test components without having to provide an entire "React environment" for the component to run in.
And that's just the point — React does just enough to pander toward maintaining a "functional image" but doesn't commit to the necessary constraints that would afford developers the actual benefits of many FP techniques.
But no, "outside world" cannot directly change the state
Of course it can - that is the whole principle of how third party libraries like Redux integrate themselves with the React component tree — especially since the introduction of hooks. And even before that the "outside world" invaded the component tree via Higher Order Components (connect, Provider pattern) which are all still "React Components".
React guards the access to component state in similar way as Haskell guards access to State Monad.
There is no "guarding" of any constraints.
It maintains control for the purpose of detecting changes to component instance state and to maintain full control over view reconciliation and scheduling.
If I can have more or less the same benefits as in a pure functional language but without having to switch from the most universal and ubiquitous language in the world that's a pretty good deal for me.
The functional programmer sounds rather like a mediæval monk,
Frankly, I couldn't care less if React was functional or not — but I am getting tired of the pretentiousness exuded by it and a significant part of it's community.
For example wickedElements is not functional in nature at all but it is brilliant in the way it leverages JavaScript and the DOM ("the platform"). It is what it is and it is good at at it.
Meanwhile there seems to be a cult-like following around React unwilling to examine and evaluate the tool objectively but instead is willing to propagate half-truths:
React is unopinionated — due to inversion of control it has a definite opinion, just not as severe as Angular.
React is functional in nature — it uses functions. So does the C language, neither of them is functional in the FP sense.
React is declarative — it manipulates the DOM so you don't have to. Meanwhile there are no benefits of declarative programming, it's just the usual BBoM; i.e. it's just an excuse to avoid learning how to manipulate the DOM or use something else that actually leverages the browser's strengths.
Alex Russell
@slightlylate
I'm not saying React was a mistake, exactly, but its apologists need to reckon honestly what it has done to the ecosystem. twitter.com/TheRealNooshu/…
09:57 AM - 29 Aug 2021
Matt Hobbs
@TheRealNooshu
@slightlylate @AndyDavies @samthor
That image tells quite a story doesn't it. That poor Moto G4 user! 😬 https://t.co/2CvGSowwqh
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
And during the compilation process the code is verified to comply with numerous constraints that permit the compiler to make some very specific and beneficial assumptions about the code.
I think here we have to differentiate between React and the React community. Now clearly React itself can't be responsible for the entire React ecosystem - but often the wording in the documentation or the statements by core members encourage certain notions in the community.
React's mental model is often oversimplified as
view = fn(state)— which is clearly functional as it implies view generation from state through transformation by a pure function.React actually doesn't work that way — there are two sources of state — props which is state as handed down from the owner component to the nested component and state which is "persisted and managed" by React on behalf of the component instance. So while components do generate the view they also can change state in the process - i.e. components are not enforced to be referentially transparent or in web terms idempotent. So React cannot grant the typical benefits or guarantees that a typical FP environment can.
React's reliance on immutability further feeds into the image of being functional.
Then there is the fact that the community often refers to Function Components as Functional Components.
So when it comes right down to it, one has to wonder how much of "hooks and stateful function components" actually had to do with necessary innovation or whether or not the whole "functional image" is about keeping React trendy within the web development community at large.
React predates Vue by about a year and despite its name Vue doesn't get to monopolize an entire tool category by virtue of how its name sounds.
It's not my interpretation, it's an active image being defended by a large portion of the React community. A framework, due to inversion of control, exerts a significant amount of design pressure on the structure of the "client side architecture". Calling React a library is disavowing the influence that React has as evidenced by countless sources describing React as unopinionated. Just because React is less constraining than Angular does not imply that it is "unopinionated" — it's just a matter of degree — React is very much opinionated, just not as much as Angular.
Did it return a constructor function? A factory function for component instances? At best it's bad naming because
createComponentwould have been more apt — at worst it's trendy naming because in 2013 "real programmers" used class-based object-orientation — not just plain functions and objects.Most generators used in JavaScript are not pure. And JavaScript has no controlled runtime support for lazy evaluation, so lazy evaluation is emulated with mutable state inside the function's closure.
"Purpose" perhaps but again without committing to any constraints. In order to preserve referential transparency functions operating within a state monad have a signature of
(state) => [state, result]. React function components could have easily adopted a similar signature. One benefit would have been that it would be trivial to micro test components without having to provide an entire "React environment" for the component to run in.And that's just the point — React does just enough to pander toward maintaining a "functional image" but doesn't commit to the necessary constraints that would afford developers the actual benefits of many FP techniques.
Of course it can - that is the whole principle of how third party libraries like Redux integrate themselves with the React component tree — especially since the introduction of hooks. And even before that the "outside world" invaded the component tree via Higher Order Components (connect, Provider pattern) which are all still "React Components".
There is no "guarding" of any constraints.
It maintains control for the purpose of detecting changes to component instance state and to maintain full control over view reconciliation and scheduling.
So the the Curse of the Excluded Middle is just Erik Meijer ranting again? And he can rant.
Frankly, I couldn't care less if React was functional or not — but I am getting tired of the pretentiousness exuded by it and a significant part of it's community.
For example wickedElements is not functional in nature at all but it is brilliant in the way it leverages JavaScript and the DOM ("the platform"). It is what it is and it is good at at it.
Meanwhile there seems to be a cult-like following around React unwilling to examine and evaluate the tool objectively but instead is willing to propagate half-truths: