Redux is unnecessary complexity. Anyone considering it, please do yourself a favor: check out an MVC framework and see how simple it is. Remember, when React first came out they described at as "React is the V in MVC." Adopt MVC in your project and watch your productivity soar.
Note: Some people believe that MVC implies two-way data binding. This is false.
Trying to shoehorn MVC into the front-end is also unnecessary complexity.
You can get very far with setState before you need a library like Redux to manage application state. And you can get even further if you use something like Apollo or Relay to handle data fetching. Then your productivity will really soar!
(For me, React + Apollo feels as magic as Rails did ten years ago.)
I've spent most of my time as a back end developer, occasionally dabbling in some front end code in various MVC frameworks. I always hated it and found it to be tedious.
I recently took up react+redux for a new project and for the first time feel like I'm developing for the UI in a way that makes sense and feel like I'm able to accomplish things way faster than with other clunky frameworks.
So what is the problem solved by Redux? I don't see a simple explanation of that in your write up. Most people struggle when asked this question. Some people go on about "time travel" and other fancy things that have nothing to do with the business problem you're trying to solve. Other people talk about "single source of truth" as if that didn't exist before Redux.
This was a really long article so you may probably missed my reasoning for using redux. I'm copying from the "Introduction to redux section" (which comes right after the "Introduction"):
"I have to say that I got interested in redux because of all that buzz this framework generated. However, I got really interested in it when I understood how close its philosophy was to functional programming - this, when combined with the usage of react functional components will enable you to write great code and (most important for me) really enjoy coding with it [...]"
So, for me the reason for using redux is its functional programming related philosophy. Ofcourse there are other js frameworks that are more functional (in the fp meaning of the word functional) like hyperapp, choo and definitely many others I'm not aware of but most of them built on the concepts of react functional components and redux, and redux is much more popular.
Sorry, to me that's an unsatisfying answer. You are not saying what problem redux is solving for you. "It is like functional programming" does not even attempt to explain what the problem being solved is.
First, "pure functions" are generally agreed to be easier to test and easier to understand, because they only rely on their inputs, and don't modify anything outside of the function. In a real application of any kind, you realistically can't write the entire app as pure functions. But, writing more of your codebase as pure functions means more of it is easily testable and understandable overall.
Second, while the OOP vs FP debate is never-ending, FP does lead to some nice forms of reusability via composition.
With Redux, you are intended to write your "reducers" as pure functions. It's up to you whether those reducers have complex logic or simply return the values they were given in the actions, but the reducers (which control the actual state updates) should all be pure, and therefore easily testable and understandable. Reducers can also be composed together to add new behaviors, such as:
In addition, writing pure functions with no side effects, in conjunction with dispatching plain object actions, is what makes Redux's time travel debugging feasible. (That's not to say it's impossible to implement time travel in other ways, just that those aspects of Redux's design make it very straightforward to implement time travel.)
The problem is people creating different data architectures on every single project they create.
Redux specifies a unidirectional data flow with a single source of truth. And then it gives you very detailed tooling with which to debug this, and an ecosystem of middlewares to augment the incredibly basic/boilerplatey API either to simplify logic or to add extra features (for example, analytics).
Writing this from my phone so I cannot be as verbose as I want to be.
I can not speak for every case, so I will talk about why I sometimes use it in React:
First off, there is a synergistic effect where React handles data coming from above in the hierarchy, which Redux facilitates.
Secondly, it can be very hard to keep track of what components are handling what logic in large applications so having it abstracted away in an easy to test way is considered a win for many.
That is the good overview I feel, there's also that popular Dan Abramov medium post[0] that deals with it. I do believe redux is overused, and people would benefit from weighing whether simple react is good enough for a project, buy I understand the risk you feel you take on if the scope runs away and suddenly you need to do a costly migration to redux later on in the project where it can be a lot harder to do so.
One benefit is that you have explicit events that create specific state changes. Your app is a succession of these events that certainly help when debugging and thinking about the potential states your app can be in.
Like other state management solutions, it also 'writes' all your shouldComponentUpdate methods for you.
There's been many comparisons made to event sourcing, but the actual semantics of the dispatched actions are up to you. You might dispatch `USER_LOGGED_IN`, or you could dispatch `SET_USER_LOGGED_IN_STATUS` (ie, "past-tense event that occurred" vs "present-tense imperative set some state"). Redux doesn't care how you name your actions. There's been lots of arguments over how action semantics should be viewed. I recapped some of the discussion in my post 'The Tao of Redux, Part 2 - Practice and Philosophy" ( http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... ).
This tutorial is pretty good, if a bit quirkily formatted.
I'm a Redux maintainer, and I'd like to toss out a bunch of additional resources for learning Redux.
First, I do recommend that people start by reading the official docs [0], and watching Dan Abramov's videos on Egghead [1].
Next, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at [2] . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, Redux, and much more. The list has a category containing many other Redux tutorials [3] (and the tutorial linked here is already in that list).
I published an "Intro to React (and Redux)" presentation at [4] , which is a good overview of the basic concepts for both React and Redux. I also frequently publish blog posts on Redux-related topics. I have a tutorial series on my blog called "Practical Redux" [5], which is intended to demonstrate a variety of useful React+Redux concepts and techniques in the context of a sample application, and my "Idiomatic Redux" blog series [6] discusses things like why certain Redux usage patterns exist in the first place, and why I consider certain approaches to be good or bad
I highly recommend that anyone interested in React or Redux check out the Reactiflux chat channels on Discord [7]. It's a great place to hang out, learn, and ask questions, and there's always some people online who are happy to help answer questions. I'm usually online there evenings US EST.
Finally, I personally am always happy to answer questions about how to learn or use React and Redux. Please feel free to ping me on Reactiflux, Twitter, Reddit, HN, or anywhere else you happen to see me :) I'm also keeper of the Redux docs, and always open to suggestions for improvements and offers to help make them better.
Holding application state in a tree is nothing new. It is as old as software development itself. You don't need Redux for that. Actions and reducers are not solving any problems. If your application needs undo/redo then that's understandable otherwise get/set methods are all you need.
Redux is just one piece of the puzzle. Let me try to explain the problem it solves. Let's say if you are building a complex SPA with lot of UI components in the view and state changes impacts several parts of the view. You can build this view in several ways:
* Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters.
* AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows.
* React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable.
Also, I know keeping application state as a single state tree is nothing new. I started this side project (https://github.com/guptag/FinCharts) almost four years ago with React/Immutable.js without any state management libraries (recently moved to electron from nodewebkit). But this code won't scale in large teams (entire ui state is declared in one file, cannot extend the functionality like Redux's middleware support etc).
None of these problems are unique to web development. How do you solve these problems in iOS? In iOS you use MVC, and the Application object holds the state as a tree. MVC has a better solution to all these problems.
Being able to do so is certainly a cool feature. But I've built a lot of apps prior to Redux and never felt like state replays were a must for debugging.
There are various ways to debug state in a React app that uses setState. React devtools show each component's state, and you can combine that with breakpoint debugging as per to figure out how you got there.
Yeah, you can use breakpoints, but...that's awful. Like, it feels like crap to do, you end up stuck in half-transactions and other nonsense because you have no better options. The use of Redux (or any other functionally-oriented action-based state system, I was writing them in Java and C# long before I ever used Redux) enables powerful stuff that, yeah, might not be a "must"--but being a "must" and being a transformatively powerful tool that requires very little cognitive overhead to leverage aren't that far off.
No, if you get/set methods that doesn't imply javascript with jquery! I am using React, but not ReactRouter or Redux. I hold my application state in a tree, and the tree nodes have get/set methods. My state tree is not immutable. I think "immutable way of changing state" is an oxymoron.
Breakpoints cannot replay. They can pause and continue playing.
The inability to examine a time series of data after-the-fact and resume from any point makes this approach significantly, significantly worse. Like, I've done it just as you have, and I'd under no circumstances go back. It's so bad that I've basically built action-pattern systems in other languages (before using Redux, actually).
Functional tooling and composition with managed side effects is fucking awesome and doing otherwise verges on footgunning if it doesn't camp right out there.
I guess you must be having a whole different set of problems than me. I also use Redux, have not found time travel to be a boost to my productivity. I choose Redux because of the simplicity around state management, and having it all centralised in a store is a nice pattern. (Don't really get other commenters claiming that this isn't new - I don't see the relevance).
It depends on the complexity of the application. If I am happy with the performance profile with mutable state then going with immutable state is obviously an overkill. These optimizations matter when React spends lot of time diffing the virtual dom of the entire app component for every state change.
I don't have an example with mutable state but for React + Redux, click on the benchmark perf test page @ https://github.com/guptag/js-frameworks. With 1500 tickers added to the page and with an price update happening every 10ms, React/Redux updates the view within 5ms (on my machine) and consistently maintains 60fps. This is when React does the virtual diffing of only one ticker component whose state is changed and skipping the rest (because of React-Redux's immutability checks). It's going to take more time if React spends diffing the entire app for every update (unfortunately, I don't have a measurement with mutable state as I built this page to compare with AngularJS).
We can easily measure and make a call whether immutability is needed for an app or not.
32 comments
[ 0.17 ms ] story [ 75.4 ms ] threadNote: Some people believe that MVC implies two-way data binding. This is false.
You can get very far with setState before you need a library like Redux to manage application state. And you can get even further if you use something like Apollo or Relay to handle data fetching. Then your productivity will really soar!
(For me, React + Apollo feels as magic as Rails did ten years ago.)
I recently took up react+redux for a new project and for the first time feel like I'm developing for the UI in a way that makes sense and feel like I'm able to accomplish things way faster than with other clunky frameworks.
"I have to say that I got interested in redux because of all that buzz this framework generated. However, I got really interested in it when I understood how close its philosophy was to functional programming - this, when combined with the usage of react functional components will enable you to write great code and (most important for me) really enjoy coding with it [...]"
So, for me the reason for using redux is its functional programming related philosophy. Ofcourse there are other js frameworks that are more functional (in the fp meaning of the word functional) like hyperapp, choo and definitely many others I'm not aware of but most of them built on the concepts of react functional components and redux, and redux is much more popular.
First, "pure functions" are generally agreed to be easier to test and easier to understand, because they only rely on their inputs, and don't modify anything outside of the function. In a real application of any kind, you realistically can't write the entire app as pure functions. But, writing more of your codebase as pure functions means more of it is easily testable and understandable overall.
Second, while the OOP vs FP debate is never-ending, FP does lead to some nice forms of reusability via composition.
With Redux, you are intended to write your "reducers" as pure functions. It's up to you whether those reducers have complex logic or simply return the values they were given in the actions, but the reducers (which control the actual state updates) should all be pure, and therefore easily testable and understandable. Reducers can also be composed together to add new behaviors, such as:
In addition, writing pure functions with no side effects, in conjunction with dispatching plain object actions, is what makes Redux's time travel debugging feasible. (That's not to say it's impossible to implement time travel in other ways, just that those aspects of Redux's design make it very straightforward to implement time travel.)Redux specifies a unidirectional data flow with a single source of truth. And then it gives you very detailed tooling with which to debug this, and an ecosystem of middlewares to augment the incredibly basic/boilerplatey API either to simplify logic or to add extra features (for example, analytics).
I can not speak for every case, so I will talk about why I sometimes use it in React:
First off, there is a synergistic effect where React handles data coming from above in the hierarchy, which Redux facilitates.
Secondly, it can be very hard to keep track of what components are handling what logic in large applications so having it abstracted away in an easy to test way is considered a win for many.
That is the good overview I feel, there's also that popular Dan Abramov medium post[0] that deals with it. I do believe redux is overused, and people would benefit from weighing whether simple react is good enough for a project, buy I understand the risk you feel you take on if the scope runs away and suddenly you need to do a costly migration to redux later on in the project where it can be a lot harder to do so.
[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Like other state management solutions, it also 'writes' all your shouldComponentUpdate methods for you.
I'm a Redux maintainer, and I'd like to toss out a bunch of additional resources for learning Redux.
First, I do recommend that people start by reading the official docs [0], and watching Dan Abramov's videos on Egghead [1].
Next, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at [2] . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, Redux, and much more. The list has a category containing many other Redux tutorials [3] (and the tutorial linked here is already in that list).
I published an "Intro to React (and Redux)" presentation at [4] , which is a good overview of the basic concepts for both React and Redux. I also frequently publish blog posts on Redux-related topics. I have a tutorial series on my blog called "Practical Redux" [5], which is intended to demonstrate a variety of useful React+Redux concepts and techniques in the context of a sample application, and my "Idiomatic Redux" blog series [6] discusses things like why certain Redux usage patterns exist in the first place, and why I consider certain approaches to be good or bad
I highly recommend that anyone interested in React or Redux check out the Reactiflux chat channels on Discord [7]. It's a great place to hang out, learn, and ask questions, and there's always some people online who are happy to help answer questions. I'm usually online there evenings US EST.
Finally, I personally am always happy to answer questions about how to learn or use React and Redux. Please feel free to ping me on Reactiflux, Twitter, Reddit, HN, or anywhere else you happen to see me :) I'm also keeper of the Redux docs, and always open to suggestions for improvements and offers to help make them better.
[0] http://redux.js.org/
[1] https://egghead.io/series/getting-started-with-redux
[2] https://github.com/markerikson/react-redux-links
[3] https://github.com/markerikson/react-redux-links/blob/master...
[4] http://blog.isquaredsoftware.com/2017/02/presentation-react-...
[5] http://blog.isquaredsoftware.com/series/practical-redux/
[6] http://blog.isquaredsoftware.com/series/idiomatic-redux
[7] https://www.reactiflux.com
I recently published an overview of Redux here - https://medium.com/@guptagaruda/introduction-to-redux-and-mo...
* Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters.
* AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows.
* React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable.
I am not saying all these things are needed for every SPA app out there. But these optimizations are needed for complex and performance sensitive applications. Check this out - https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Also, I know keeping application state as a single state tree is nothing new. I started this side project (https://github.com/guptag/FinCharts) almost four years ago with React/Immutable.js without any state management libraries (recently moved to electron from nodewebkit). But this code won't scale in large teams (entire ui state is declared in one file, cannot extend the functionality like Redux's middleware support etc).
('Cause this is why we use Redux.)
There are various ways to debug state in a React app that uses setState. React devtools show each component's state, and you can combine that with breakpoint debugging as per to figure out how you got there.
The inability to examine a time series of data after-the-fact and resume from any point makes this approach significantly, significantly worse. Like, I've done it just as you have, and I'd under no circumstances go back. It's so bad that I've basically built action-pattern systems in other languages (before using Redux, actually).
Functional tooling and composition with managed side effects is fucking awesome and doing otherwise verges on footgunning if it doesn't camp right out there.
I don't have an example with mutable state but for React + Redux, click on the benchmark perf test page @ https://github.com/guptag/js-frameworks. With 1500 tickers added to the page and with an price update happening every 10ms, React/Redux updates the view within 5ms (on my machine) and consistently maintains 60fps. This is when React does the virtual diffing of only one ticker component whose state is changed and skipping the rest (because of React-Redux's immutability checks). It's going to take more time if React spends diffing the entire app for every update (unfortunately, I don't have a measurement with mutable state as I built this page to compare with AngularJS).
We can easily measure and make a call whether immutability is needed for an app or not.