Chapter 12. Flux

In the previous chapter, we took a look at the various tools in the React ecosystem that are useful in the whole lifetime of an application—development, testing, and production. We also saw how React improves the developer experience using developer tools. We learned about the various testing tools that can be used with React. To summarize it, we saw how to use build tools such as Webpack and Browserify and how they can be used with React.

In this chapter, we are going to dive deep in Flux as an architecture. We have seen how problems arise during data sharing across components. We will see how we can overcome them by having a single point of data store. Next, we will check out how to use React to overcome this.

Dispatcher acts as a central hub to manage this data flow and communication and how Actions invoke them. Finally, we will we take a look at the complete data flow that takes place, while building our Social Media Tracker application.

In this chapter, we will cover the...

Flux architecture and unidirectional flow

"Hey Mike and Shawn!" entered Carla, on a bright morning.

"Hi Carla, how are you today?"

"Wonderful. The previous app that you build was nice, the clients liked it. They will soon add more features to it. Meanwhile, we have got another small app to build."

"Oh, nice. What are we planning to build?" inquired Mike.

"We need to build a kind of social tracker. To start with, we show a user's reddits, tweets, and so on. We will later extend it to display other information."

"Got it," iterated Shawn.

"Have a good day; I will leave it to you."

"So Shawn, what do you think about the new project?"

"It should be exciting. Umm… can we explore Flux and use it in the app? We had discussed it when we were building the last app."

"Yeah, we can. This will be the perfect opportunity to see how Flux works. Before we start using it, let's go through what Flux actually is."

"Flux is a simple architecture for React to make use of unidirectional flow. We have discussed previously...

Flux actions

"Now we need to define the actions types that we are going to refer to as constants at various places, such as sending the type from Actions to store, and in our store, deciding what action type has been passed to store to take appropriate actions.

//SocialConstants.js
var keyMirror = require('keymirror');

module.exports = keyMirror({
  FILTER_BY_TWEETS: null,
  FILTER_BY_REDDITS: null,
  SYNC_TWEETS: null,
  SYNC_REDDITS: null

});

"Here, we are using the https://github.com/STRML/keyMirror package to create keys and values for the object based on the keys. This will convert into object similar to below."

{
FILTER_BY_TWEETS: 'FILTER_BY_TWEETS', 
…
}

"This is handy when adding new keys to not repeat the same contents again."

"We can now start using the action constants. They represent four actions that we are going to perform, as follows:"

• SYNC_TWEETS: This fetches the tweets for a given user

• SYNC_REDDITS: This fetches the reddits for a give topic

• FILTER_BY_TWEETS: This only displays...

Flux stores

"Cool, it looks like now we are all set to create our store."

"Yup Shawn. We will start by defining the state object that we will keep on updating and using as a store."

var AppDispatcher = require('../dispatcher/AppDispatcher');
var EventEmitter = require('events').EventEmitter;
var SocialConstants = require('../constants/SocialConstants');
var assign = require('object-assign');
var _ = require('underscore');

var CHANGE_EVENT = 'change';

var _state = {
  tweets: [],
  reddits: [],
  feed: [],
  showTweets: true,
  showReddits: true
};

"We have also defined a CHANGE_EVENT constant that we use as an identifier to listen to events of the change type from the event emitter in our store."

"We then define a method to update the states, creating a new one."

function updateState(state) {
  _state = assign({}, _state, state);
}

"This merges the new properties that need to be updated and merged into the existing state and updated the current state."

"Cool, this looks somewhat similar to the...

Summary

We did a deep dive in Flux as an architecture. We saw Dispatcher act as a central hub to transmit our data and Actions to process them. We saw how the main responsibility to manipulate the state and update itself was delegated to the stores themselves. Finally, we saw how they were tied up together and made it easy to be used in views and share stores across the components.