Recently I conducted a preliminary study on developing an E-commerce site and discovered that redux and reflux both come from flux architecture in Facebook and that both are popular. I am confused about the difference between the two.
When should I use redux vs reflux, and which is most flexible during the development phase of an e-commerce web application?
I wanted to write another answer focusing on the specific difference between Reflux and Redux. @Mijamo goes into the core of why they originated as different things and is a very good summary if you have context, but I came to this question to know specifically the difference between the two from a development perspective. Seeing as how I just went in and read all the things, I wanted to write an answer. I will update this answer with more code examples.
Before we go into this, I think one thing that we should keep in mind moving forward is thinking about current Flux and how it currently handles scaling an application with many components or many different pieces of states that needs to be managed. This is a pretty good talk at React NYC: Scaling Flux that goes into the problem and the solution they arrive at is not too far off from what Reflux and Redux allow you to do but in a nutshell a big question is "What do we do when we have components that have some shared state that they all need to keep in mind of? How do we handle and scale that?" Ultimately an answer a lot of these frameworks arrive at is we need this idea of a global state. Inevitably, both frameworks introduce some similar concepts to achieve this which we'll go into below.
Because I will need to reference a comparison of Flux, I just want to show a quick overview way Flux works with the picture below:
In Reflux, there is no dispatcher, and the View Components directly communicate via the components through actions.
+---------+ +--------+ +-----------------+
¦ Actions ¦------>¦ Stores ¦------>¦ View Components ¦
+---------+ +--------+ +-----------------+
^ ¦
+--------------------------------------+
In terms of how it differentiates itself from Flux, there is not too much. You still create your own actions and create your own stores, and you still have your stores listen to actions. I believe the biggest difference is that in order to have the View components submit actions directly to the store rather than going through a dispatcher, the Components have a store property which comes from extending from Reflux.Component rather than React.Component so that it has a way to directly hook into a store. i.e. this example
class MyComponent extends Reflux.Component
{
constructor(props)
{
super(props);
this.state = {}; // our store will add its own state to the component's
this.store = StatusStore; // <- just assign the store class itself
}
render()
{
var flag = this.state.flag; // <- flag is mixed in from the StatusStore
return <div>User is {flag}</div>
}
}
You also have the ability to hook into multiple stores (there is a prop I believe called stores which takes an array and Reflux also ships with the ability edit mapStoreToState in case you wanted to control specifically how the stores pass over state to the components.
Naturally because you are using a component that Reflux ships with, you should probably read their documentation on Reflux Component and how to properly make components with this in mind
Last thing I'll note is above I mentioned the big problem was global state and how does this address that. Reflux does have a Reflux.GlobalState that can be contributed to as long as you set ids on your Stores. The link above goes a lot more detail into it but with this, you can access them via Reflux.GlobalState.[StoreID].[property] where StoreID is the id you assign the store and property is the actual piece of state you want to access.
Redux in and of itself changes a lot of things and also kills the idea of dispatchers. Before I go really deep into it, I want to highlight the three principles they mention in their docs.
In Redux, there is really only one global state you have to deal with and that is the global state for your application (addressing the big problem). While you still have actions and stores, the stores themselves are simply responsible for keeping track of their own state in the global state tree, allowing you to dispatch actions to make changes to the state tree, and allowing you to access the state. You can also still put listeners on these stores via subscribe.
A large motivation of this goes into the first two principles. In Flux or even Reflux, if you wanted to make sure nothing was mutating the state when you didn't want it to (because technically you can access and change state in the stores whenever you want), you would depend on things like ImmutableJS to make sure you weren't accidentally mutating the state. Redux on the other hand makes it so you can only access the state via the stores/selectors and making changes only via dispatching actions (the third principle).
An interesting thing to note is that while Reflux and Flux had actions where in the stores you would listen and determine what state change to do, the stores in Redux simply dispatch a message with the payload you want and then that goes through a giant switch statement to determine what it should do with the state tree -- this is what they refer to as a reducer. This isn't any different from how Flux has reduce in its Stores but Redux rips this concept out as its own thing and your global state tree goes through a rootReducer (Redux ships with a nice function for you to combineReducers and make a rootReducer). A good way to think about it is you dispatch a change to the giant state tree and then whatever changes you want, it gets reduced or condensed to the final state you want. This actually influences how redux sets up a lot of things so it tells React how to rerender (assuming you are using Redux with React).
The data flow of Redux talked about really well in the link I mentioned above but there is also a pretty good infographic I have attached
So core differences is really
Hopefully this gives more insight to the core differences between them.
Flux, Reflux and Redux (and many other similar libraries) are all different ways to handle transversal data management.
Basic React components work fine with parent-children relationships, but when you have to provide and update data from different parts of the app which are not directly connected it can become quickly messy. Those libraries provide stores and actions (and other mechanisms) to maintain and update such data.
Flux is the original solution developed by Facebook (just like React), it is powerful but probably not the easiest or readable. Reflux was developed partly to make it easier and clearer. The main difference is that in Reflux every piece of data has its own store and actions, which make it very readable and easy to write. Unfortunately Reflux is not so much actively developed anymore, the author is looking for maintainers. But all in all I would say Reflux is a more elegant alternative to Flux.
Redux is another solution, which has become the most popular so far. Its advantage is that it provide nested stores with immutable content so that you can easily implement previous/next feature and have transversal actions that have impact on many parts of the store. The disadvantages of redux are that it is quite verbose and has many more concepts than Flux or Reflux. For the same basic actions it will need much more code, and the async implementation is not the cleanest. It is definitively powerful and scalable.
Here is a link that talks about it more extensively: http://jamesknelson.com/which-flux-implementation-should-i-use-with-react/
I wanted to write another answer focusing on the specific difference between Reflux and Redux. @Mijamo goes into the core of why they originated as different things and is a very good summary if you have context, but I came to this question to know specifically the difference between the two from a development perspective. Seeing as how I just went in and read all the things, I wanted to write an answer. I will update this answer with more code examples.
Before we go into this, I think one thing that we should keep in mind moving forward is thinking about current Flux and how it currently handles scaling an application with many components or many different pieces of states that needs to be managed. This is a pretty good talk at React NYC: Scaling Flux that goes into the problem and the solution they arrive at is not too far off from what Reflux and Redux allow you to do but in a nutshell a big question is "What do we do when we have components that have some shared state that they all need to keep in mind of? How do we handle and scale that?" Ultimately an answer a lot of these frameworks arrive at is we need this idea of a global state. Inevitably, both frameworks introduce some similar concepts to achieve this which we'll go into below.
Because I will need to reference a comparison of Flux, I just want to show a quick overview way Flux works with the picture below:
In Reflux, there is no dispatcher, and the View Components directly communicate via the components through actions.
+---------+ +--------+ +-----------------+
¦ Actions ¦------>¦ Stores ¦------>¦ View Components ¦
+---------+ +--------+ +-----------------+
^ ¦
+--------------------------------------+
In terms of how it differentiates itself from Flux, there is not too much. You still create your own actions and create your own stores, and you still have your stores listen to actions. I believe the biggest difference is that in order to have the View components submit actions directly to the store rather than going through a dispatcher, the Components have a store property which comes from extending from Reflux.Component rather than React.Component so that it has a way to directly hook into a store. i.e. this example
class MyComponent extends Reflux.Component
{
constructor(props)
{
super(props);
this.state = {}; // our store will add its own state to the component's
this.store = StatusStore; // <- just assign the store class itself
}
render()
{
var flag = this.state.flag; // <- flag is mixed in from the StatusStore
return <div>User is {flag}</div>
}
}
You also have the ability to hook into multiple stores (there is a prop I believe called stores which takes an array and Reflux also ships with the ability edit mapStoreToState in case you wanted to control specifically how the stores pass over state to the components.
Naturally because you are using a component that Reflux ships with, you should probably read their documentation on Reflux Component and how to properly make components with this in mind
Last thing I'll note is above I mentioned the big problem was global state and how does this address that. Reflux does have a Reflux.GlobalState that can be contributed to as long as you set ids on your Stores. The link above goes a lot more detail into it but with this, you can access them via Reflux.GlobalState.[StoreID].[property] where StoreID is the id you assign the store and property is the actual piece of state you want to access.
Redux in and of itself changes a lot of things and also kills the idea of dispatchers. Before I go really deep into it, I want to highlight the three principles they mention in their docs.
In Redux, there is really only one global state you have to deal with and that is the global state for your application (addressing the big problem). While you still have actions and stores, the stores themselves are simply responsible for keeping track of their own state in the global state tree, allowing you to dispatch actions to make changes to the state tree, and allowing you to access the state. You can also still put listeners on these stores via subscribe.
A large motivation of this goes into the first two principles. In Flux or even Reflux, if you wanted to make sure nothing was mutating the state when you didn't want it to (because technically you can access and change state in the stores whenever you want), you would depend on things like ImmutableJS to make sure you weren't accidentally mutating the state. Redux on the other hand makes it so you can only access the state via the stores/selectors and making changes only via dispatching actions (the third principle).
An interesting thing to note is that while Reflux and Flux had actions where in the stores you would listen and determine what state change to do, the stores in Redux simply dispatch a message with the payload you want and then that goes through a giant switch statement to determine what it should do with the state tree -- this is what they refer to as a reducer. This isn't any different from how Flux has reduce in its Stores but Redux rips this concept out as its own thing and your global state tree goes through a rootReducer (Redux ships with a nice function for you to combineReducers and make a rootReducer). A good way to think about it is you dispatch a change to the giant state tree and then whatever changes you want, it gets reduced or condensed to the final state you want. This actually influences how redux sets up a lot of things so it tells React how to rerender (assuming you are using Redux with React).
The data flow of Redux talked about really well in the link I mentioned above but there is also a pretty good infographic I have attached
So core differences is really
Hopefully this gives more insight to the core differences between them.
© 2022 - 2024 — McMap. All rights reserved.