Honest question: why are React developers so fixated on functional programming? Why are objects - bundles of state and action that represent entities in the problem domain - automatically painted as an antipattern?
1. It's not. React has had classes and states from the very begining. In fact, purely functional only views came in React 0.14.
2. That said, it really does make coding, debugging, and reasoning about views so much easier. When I have a bug in my React/Redux app, I can look at the Redux state, and figure out the cause of the bug right then and there. I'm not looking for some variable that accidentally got changed five steps ago.
My bug is either in:
(a) How I went from application state n-1 to n, or
(b) How my current application state is rendered in my views
Both of these are very fixable.
...of course, I do also have stateful React views in my app, and code with side-effects, because being "pure" all the time isn't always practical. If the bug is in those places, I'm in for a much longer debug.
That's a snarky reply, but there is a kernel of truth. OO was practically invented for GUIs (Smalltalk). Throwing it out entirely on principle just makes large programs harder to understand, IMHO.
Funnily enough, React + Redux is "Global god state + functions", with a bit of dispatch sprinkled in. Not too far away really.
I definitely see the benefits of having a functional approach to defining UIs. My code is _somewhat_ clear, clearer than what it would have been with say, WinForms or something of the like. Going purely functional everywhere is just devs cargo culting.
Once I got in touch with React, I got interested in FP. Then I read the "Mostly Adequate Guide to Functional Programming" [1] and it was kind of an revelation for me.
I still do OOP, and I'm far, far away from being an FP expert, but I think if I'd take the effort to learn a real FP language then I probably wouldn't want to go back to OOP, and that's something I fear :) I've read a few blog posts from people who stated that learning FP kind of made them "unemployable", because they suddenly saw all the problems and annoyances that OOP brings with it (unfortunately I can't find the link anymore).
This quote regarding OOP by Joe Armstrong, the creator of Erlang, is quite fitting: "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle."
When you say that, what exactly do you mean by it?
I would write all of this in my own words, but it would become really long and I don't have the time at the moment. I tried to find the original article I read, but I'm unable to, but here is a similar article I just found: https://medium.com/@cscalfani/goodbye-object-oriented-progra...
I'd understand if the inflammatory writing style and the memes are not yours, but I skimmed through it and I think it does explain some of the problems well. I'm sure there are better written articles on this subject, but I have to leave now unfortunately.
My only regret after becoming comfortable with functional programming in JS (and eventually, even more robust techniques in Haskell, OCaml, and Scala) is not pushing harder for a functional approach in work projects that could have really benefited from the functional paradigm.
We have a strictly defined state object that is used throughout our entire application. Because we made a contract with redux, every transaction is readable and transparent.
Writing tests for our UI layer has never been easier with React. While we do have local state inside some react components, when we use redux to pass state to our react components, they become extremely easy to test, because they turn into pure functions.
When using something like jQuery, you wouldn't just look at each frame of your state to determine how the UI would look, you would also have to look at the transitional states between A and B. Transitional states are much more difficult to understand because of the contextual implications.
Our UI layer is completely separate from our business logic and we get it automatically. Without any code modification we were able to target our large application into a CLI app just by adding a new UI layer.
There's certainly Redux movement, because it solves few important problems almost for free. But React isn't bound to Redux in any way.
I'm a swift / go guy mainly but I've been looking at this space for a while and the only sane approach to me looks like ClojureScript with reagent / reframe or something along those lines.
But in a nontrivial number of cases it isn't, and then I use methods.