You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 4, 2019. It is now read-only.
There are many great tutorials and boilerplate apps online--linked to in the footer of this post--and even documentation for redux and react itself is fantastic, so for the purposes of this tutorial I'd like to focus on purely how we switched from using reflux to redux in production. You don't necesarilly need a background in Reflux or Redux to understand what's going on, but at least a working knowledge of React is recommended--bonus points for [flux](https://facebook.github.io/flux/docs/overview.html)knowledge as well. This tutorial was initilly written to onboard other WeWork engineers, hence its density, and is intended for beginners and experts alike.
10
+
There are many great tutorials and boilerplate apps online--linked to in the footer of this post--and even documentation for redux and react itself is fantastic, so for the purposes of this tutorial I'd like to focus on purely how we switched from using reflux to redux in production. You don't necesarilly need a background in Reflux or Redux specifically to understand what's going on, but at least a working knowledge of React and [Flux](https://facebook.github.io/flux/docs/overview.html) is recommended.
11
11
12
-
Over the last week or so we took the time to convert our ES5 React Reflux implementation of our [location's flow](https://www.wework.com/locations/new-york-city) into a brand spanking new ES6/7 React ***Redux*** implemenation. We'll go over 3 important examples in our data flow: saving the state of the ui in a store, fetching data from an external API to hydrate our store, and filtering data that is already in our store. This might be redundant, but you'll also get some transitioning from ES5 to ES6/ES7 bonus tips.
12
+
Over the last week or so we took the time to convert our ES5 React Reflux implementation of our [location's flow](https://www.wework.com/locations/new-york-city) into a brand spanking new ES6/7 React ***Redux*** implemenation. We'll go over 3 important examples in our data flow: saving the state of the ui in a store, fetching data from an external API to hydrate our store, and filtering data that is already in our store. This might be redundant, but you'll also get some transitioning from ES5 to ES6/ES7 examples built in.
13
13
14
14
## EXAMPLE 1: Store the State of your UI in your...Store
15
15
16
-
One of the best parts or React, or any componentized framework for that matter is that it's a *declarative* framework--"telling the 'machine' what you would like to happen, and let the computer figure out how to do it"--vs an *imperative* framework--"telling the machine how to do something, and as a result what you want to happen will happen" ([source](http://latentflip.com/imperative-vs-declarative/)).
17
-
18
16
Let's think about something as simple as hiding or showing extra filters in a list application.
19
17
20
18
Going from a state where most of the location filters are hidden, with a link that says "More Filters"...
@@ -27,7 +25,7 @@ Going from a state where most of the location filters are hidden, with a link th
27
25
28
26
### jquery - the old standby:
29
27
30
-
In an *imperative* example using jquery you could have a listener to that specific link, and when it's clicked have it toggle the hidden filters container:
28
+
Using jQuery you could have a listener to that specific link, and when it's clicked have it toggle the hidden filters container:
Problem with this is, it's super specific, it's not the most reusable piece of code in the world, and it usually just gets dumped into a compiled application.js file that will be hard to find in a production level codebase.
39
37
40
-
How can we do better???
38
+
### Reflux - the first attempt:
41
39
42
-
Let's now look at the more *declarative* example with our initial Reflux implementation.
40
+
What if we had access to a boolean that told us whether we should show or hide the hidden filters container? Our React components would listen to that boolean so it would know what to display, then our link component would simply dispatch an action that would toggle that boolean when clicked.
43
41
44
-
### Reflux - the first attempt:
42
+
Quick flux refresher from their docs:
45
43
46
-
What if we had access to a boolean that told us whether we should show or hide the hidden filters container? Our React components would listen to that boolean so it would know what to display (...*declarative*), then our link component would simply dispatch an action that would toggle that boolean when clicked.
Following the [Reflux pattern](https://github.com/reflux/refluxjs), let's declare an action--showFiltersActions--to tell the store that we want to toggle the state of "showFilters", and let's create a single store--showFiltersStore--to hold the record of this state.
49
47
50
48
```js
49
+
50
+
////////// ACTION: //////////
51
51
// src/actions/show_filters_actions.js
52
52
var ShowFiltersActions = {};
53
53
ShowFiltersActions.toggle=Reflux.createAction();
54
54
module.exports= ShowFiltersActions;
55
55
56
56
57
57
58
+
////////// STORE: //////////
58
59
// src/stores/show_filters_store.js
59
60
var ShowFiltersActions =require('../actions/show_filters_actions');
I know this might seem like overkill essentially replacing 3 lines of jquery and a few lines of html with 4 different files between the actions, stores, and components, but this method actually leads to cleaner more reusable--and in my opinion more readable--code, as you start to extend the functionality of your application. What if you wanted to carry the state of your UI through multiple pages on your application? How do you handle reloads? React allows you to handle this complexity in a structured *declarative* manner.
166
167
167
168
168
-
But this tutorial isn't about why you should use React. What about Reflux???
169
+
But this tutorial isn't about why you should use Reflux...
169
170
170
171
171
-
### Redux - Finally:
172
+
### Redux:
172
173
173
174
When you start building larger production level applications that require many types of stores and a more complex data model, reflux can start to feel a little bloated (TERRIBLE PUN). Redux is a natural successor to reflux (and other flux patterns in general).
174
175
@@ -190,7 +191,7 @@ Let's look at the Redux implementation of our showFiltersLink.
190
191
A few caveats before diving into the new code:
191
192
192
193
* We adopted the [ducks/modules](https://github.com/erikras/ducks-modular-redux) pattern from the [The React/Redux/HotReloader Boilerplate app](https://github.com/erikras/react-redux-universal-hot-example) when building our Redux actions and reducers. This is why our implementation might look slightly different from those in the Redux docs.
193
-
* As we went through the process of converting Reflux to Redux we also updated our code to the new ES6 syntax.
194
+
* As we went through the process of converting Reflux to Redux we also updated our code to ES6.
194
195
195
196
#### Redux: Building a module
196
197
@@ -199,7 +200,7 @@ The single store concept can seem a little strange coming from the reflux world.
@@ -513,7 +514,7 @@ export function fetchLocationsIfNeeded() {
513
514
514
515
A nice feature to this pattern is we dispatch the `receiveLocations()` action once data is received from the API. That forces a state change which causes our components to re-render, updating the view.
515
516
516
-
With the new locations module written, and everything already setup in EXAMPLE 1 to handle this new locations reducer. All we have to do is now connect to this part of the store in our main `<App />` component.
517
+
With the new locations module written, and everything already setup in EXAMPLE 1 to handle this new locations reducer, all we have to do is now connect to this part of the store in our main `<App />` component.
0 commit comments