sandrino-di-mattia

Principal Architect

Sandrino Di Mattia

Making it easy to reproduce end-user issues and bugs with Flux.


---

**TL;DR**: You can check out the sample application in [this Github repository](https://github.com/auth0/react-flux-debug-actions-sample)

---

Troubleshooting applications running in production is not always easy. You might get bug reports like "Nothing works!" In addition, some errors might only occur based on the data that the user is working with, and reproducing the issue could be challenging because of specific dependencies (e.g., user, API) … the list goes on and on!

There are plenty of tools available out there that can catch any errors with a stack trace and very detailed information, but even then the error might be hard to reproduce.

In this blog post, we'll show how you can leverage your existing React and Flux infrastructure in order to have a better logging and debugging experience.

## Example: Customer Service Application

The example in this blog post is a customer service application that allows you to manage open tickets. You can view the open tickets and close tickets that have been resolved.

<img src="https://images.ctfassets.net/23aumh6u8s0i/7MFsGErVECNOx4uCcnpFDx/e63340e0f1f9962375e3c48f863db7c6/react-flux-debugging-tickets" class="expand" />

John, an end user, is solving the open tickets and closing them one by one. But suddenly... a crash! So John goes ahead and opens a bug: "Nothing works!"

<img src="https://images.ctfassets.net/23aumh6u8s0i/6cXn7s2HJazm45a8Q4ikaO/6e5b6f4d28648b7919f27641c3f36ba5/react-flux-debugging-end-user" class="expand" />

Jane, a developer, is now assigned to work on the "Nothing works!" bug. Great. Luckily, their application is recording all Flux actions executed by users. These actions are linked to a user's session, so she can just go ahead and look for John's session. After that, she can replay John's session and try to figure out the problem.

<img src="https://images.ctfassets.net/23aumh6u8s0i/34RKZ1DgEy7MwjKIgsX5a9/4f9abbd929a3362f0091c66f7421a3b7/react-flux-debugging-developer" class="expand" />

Aha! While replaying John's session, an error pops up in the developer console. It looks like there might be a bug in the `Error.jsx` component.

## How does this work?

Implementing this in your own Flux applications is really easy. In our blog post about [ReactJS authentication](https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/) using Flux, we explain what a typical Flux application looks like. Actions are dispatched to stores, and stores will notify components to update themselves. So if we want to keep track of all actions, we'll need to start with the dispatcher:

```javascript
import Dispatcher from './dispatcher';
import LogActions from './actions/LogActions';

// Export the dispatch method.
export default function dispatch(action) {
  Dispatcher.dispatch(action);
  LogActions.log(action);
}
```

<include src="TweetQuote" quoteText="Actions are dispatched to stores, and stores will notify components to update themselves."/>

The `dispatch` method we're exposing here will forward the action to the dispatcher, but after that, it will forward the data to `LogActions.log`. This method will then send the action to our back-end:

```javascript
import httpClient from '../httpClient';
import LoginStore from '../stores/LoginStore'

export default {
  log: (action) => {
    console.log('Action:', action);

    if (LoginStore.sessionId && !action.debug) {
      httpClient.post(null, { url: `/sessions/${LoginStore.sessionId}/logs`, data: action }).catch(err => {
        console.log('Error sending log:', err);
      });
    }
  }
};
```

The message will first be logged to the console. This could be something you want to activate for your non-production builds. Then, if the user is logged in and it's not a "debug action", the data is posted to the back-end.

When we replay actions in a troubleshooting session, we'll mark these as "debug actions" to make sure that these actions are not sent to the server again.

And that's basically it. Our backend will store all actions in a "session" in chronological order. Then a developer might choose to replay a session:

```javascript
debugSession: (session, untilAction) => {
  console.log('Debugging session:', session);

  dispatch({ debug: true, actionType: RESET });
  dispatch({ debug: true, actionType: START_DEBUG });

  // Replay all actions with a delay.
  for (var i = 0; i < session.actions.length; i++) {
    let action = session.actions[i];

    setTimeout(() => {
      console.log(' > Dispatching debug action:', action);
      dispatch({
        ...action,
        debug: true
      });
    }, i * 250);

    if (untilAction && untilAction === action) {
      break;
    }
  }

  dispatch({ debug: true, actionType: STOP_DEBUG });
}
```

When replaying a session, we'll first dispatch the `RESET` and the `START_DEBUG` actions. The `RESET` action can be handled by all stores to reset their state (clear all data, clear alerts, etc.).

The `START_DEBUG` action tells the rest of the applications that we are now going to replay certain actions. This is very important because one thing we'll want to avoid is our application making calls to the API. So our HttpClient will not be making calls during this time (in the next section, we'll explain how this works and how we're leveraging Flux to record every request and every response so we can replay everything later without requiring interaction with the API).

Then we go over each action and dispatch it, after which we introduce a small delay. As a result, the developer will see every action that is replayed (in fast-forward, as the delay is always 250ms). And finally, the `STOP_DEBUG` action is sent to notify that we're done replaying the actions, which re-enables the HttpClient.

## Improving our API calls

When Jane was debugging John's session, we immediately noticed a bug in one of our components, so this approach is good to catch runtime errors. But what about API calls? When replaying the actions, the HttpClient will not be making any calls to our API, so how can we effectively replay and troubleshoot API calls? Well, we'll just need to dispatch an action each time we want to make a request, each time we get a successful response, and each time the API returns an error.

Here's what this could look like when we're making the request:

```javascript
{
  actionType: 'LOAD_OPEN_TICKETS',
  user: 'sandrino',
  sort: 'date'
}
```

When the request is successfully executed, we can dispatch the result.

```javascript
{
  actionType: 'LOAD_OPEN_TICKETS_SUCCESS',
  tickets: [...]
}
```

And in the case that something goes wrong, we will also dispatch this action with the actual error message:

```javascript
{
  actionType: 'LOAD_OPEN_TICKETS_FAILED',
  err: {
   message: 'The user "sandrino" has been disabled. You cannot load tickets for this user.'
  }
}
```

Frameworks like `redux` support concepts like middleware, which make it much easier to implement this in a generic way, but we'll just create a wrapper around a library like `axios` or `superagent` that handles this for us:

```javascript
class HttpClient {

  get(action, options) {
    var request = superagent.get(`${BASE_URL}${options.url}`);
    if (options.query) {
      request = request.query(options.query);
    }

    return this._execute(action, request);
  }

  post(action, options) {
    var request = superagent.post(`${BASE_URL}${options.url}`);
    if (options.data) {
      request = request.send(options.data);
    }

    return this._execute(action, request);
  }

  _execute(action, request) {
    if (debug.isActive) {
      console.log('Debug mode active - not executing Http Request:', request);
      return;
    }

    return new Promise((resolve, reject) => {
      request.end((err, res) => {
        if (err) {
          dispatch({ actionType: action + '_FAILED', err: err });
          return reject(err);
        }

        dispatch({ actionType: action + '_SUCCESS', res: res });
        return resolve(res);
      });
    });
  }
}

export default new HttpClient();
```

This class will dispatch `YOUR_ACTION` before the call is made to the API. Then, it will dispatch `YOUR_ACTION_SUCCESS` when the request has been executed or `YOUR_ACTION_FAILED` in the event of an error. This means that every request and response is dispatched and also being logged to our back-end. Thus, we can easily replay all actions, including the data returned by possible API calls, without having to interact with the actual API. This is useful if you need to reproduce an issue that occurred a few days ago for which the data might no longer exist or might have changed.

## Trying it out

The complete source of this application is available on GitHub: [https://github.com/auth0/react-flux-debug-actions-sample](https://github.com/auth0/react-flux-debug-actions-sample). Follow the instructions here to start the front-end and the back-end.

Happy troubleshooting!


Logging &amp; Debugging in React with Flux: Replaying your user’s actions

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

ReactJS authentication gets easy if you understand just a few basic concepts. Because, let’s face it. React is the new cool kid on the block.

---

**TL;DR**: You can check out a React Flux app with authentication implemented in [this Github repository](https://github.com/auth0/react-flux-jwt-authentication-sample)

---

Let’s face it. [React](https://facebook.github.io/react/) is the new cool kid on the block. Everybody is working on creating React components because it entails understanding just 2 basic concepts:

* A component is just a function
* Single-direction data flow

However, once you start creating a bigger app, you realize that just using React isn’t enough. So you start looking at [Flux](https://facebook.github.io/flux/), which is the architecture Facebook uses to create React apps.

As we learned in a previous blog post, learning how to conduct authentication in a Single Page App can get super complex. We had to learn about tokens, [JWTs](http://jwt.io/) and how to integrate them with SPAs. Learning how to do it with Flux is even harder! That’s why in this blogpost we’ll learn how to add authentication to a React Flux app.

<include src="TweetQuote" quoteText="Learning how to conduct authentication in a Single Page App can get super complex"/>


![ReactJS Authentication](https://images.ctfassets.net/23aumh6u8s0i/2wZ0usYMDTF9nwlvuclsEW/d94606742748ea6a79fd4a5edaafd3d9/pub_w_959_h_638)



## Before we start

We’ll be coding our React app using ES6 thanks to [Browserify](http://browserify.org/) and [Babelify](https://github.com/babel/babelify), and we’ll be using npm for build tools and installing dependencies. If you want to start a project with the same architecture, just clone [this seed project](https://github.com/auth0/react-browserify-spa-seed).

## Coding ReactJS Authentication!

### Login page
#### The Login component
![Login Component](https://images.ctfassets.net/23aumh6u8s0i/4xDmop13K9QA8T1pPmvsTa/01ef0dbe2f7d9f1d29fe6b0e8aee2ae2/pub_w_959_h_638)

First, let’s create our `Login` component. Its main function is rendering an input for the username and password and calling the `AuthService` when the user clicks on the login button.

```jsx
// ... imports
export default class Login extends React.Component {

  constructor() {
    this.state = {
      user: ‘’,
      password: ‘’
    };
  }

  // This will be called when the user clicks on the login button
  login(e) {
    e.preventDefault();
    // Here, we call an external AuthService. We’ll create it in the next step
    Auth.login(this.state.user, this.state.password)
      .catch(function(err) {
        console.log(“Error logging in”, err);
      });
  }

  render() {
    return (
        <form role=“form”>
        <div className=“form-group”>
          <input type=“text” valueLink={this.linkState(‘user’)}placeholder=“Username” />
          <input type=“password” valueLink={this.linkState(‘password’)} placeholder=“Password” />
        </div>
        <button type=“submit” onClick={this.login.bind(this)}>Submit</button>
      </form>
    </div>
    );
  }
}

// We’re using the mixin `LinkStateMixin` to have two-way databinding between our component and the HTML.
reactMixin(Login.prototype, React.addons.LinkedStateMixin);
```

#### The AuthService & the LoginAction
![AuthService role in ReactJS Authentication](https://images.ctfassets.net/23aumh6u8s0i/6EBkPQa2IwjXwFTF5R23mh/b9662da8029b599927e50e5ab24d2c35/pub_w_959_h_638)

Our AuthService is in charge of calling our [login API](https://github.com/auth0/nodejs-jwt-authentication-sample/blob/master/user-routes.js#L37-L54). The server will validate the username and password and return a token [(JWT)](http://jwt.io/) back to our app. Once we get it, we’ll create a [LoginAction](https://facebook.github.io/flux/docs/todo-list.html#creating-semantic-actions) and send it to all the [Stores](https://facebook.github.io/flux/docs/todo-list.html#creating-stores) using the [Dispatcher](https://facebook.github.io/flux/docs/todo-list.html#creating-a-dispatcher) from Flux.

```jsx
// AuthService.js
// ... imports
class AuthService {

  login(username, password) {
    // We call the server to log the user in.
    return when(request({
      url: ‘http://localhost:3001/sessions/create',
      method: ‘POST’,
      crossOrigin: true,
      type: ‘json’,
      data: {
        username, password
      }
    }))
    .then(function(response) {
        // We get a JWT back.
        let jwt = response.id_token;
        // We trigger the LoginAction with that JWT.
        LoginActions.loginUser(jwt);
        return true;
    });
  }
}

export default new AuthService()
```

```js
// LoginAction.js
// ... imports
export default {
  loginUser: (jwt) => {
    // Go to the Home page once the user is logged in
    RouterContainer.get().transitionTo(‘/‘);
    // We save the JWT in localStorage to keep the user authenticated. We’ll learn more about this later.
    localStorage.setItem(‘jwt’, jwt);
    // Send the action to all stores through the Dispatcher
    AppDispatcher.dispatch({
      actionType: LOGIN_USER,
      jwt: jwt
    });
  }
}
```

You can take a look at the router configuration [on Github](https://github.com/auth0/react-flux-jwt-authentication-sample/blob/gh-pages/src/app.jsx#L11-L29), but it’s important to note that once the `LoginAction` is triggered, the user is successfully authenticated. Therefore, we need to redirect him or her from the Login page to the Home. That’s why we’re adding the URL transition in here.

#### The LoginStore
![Dispatcher and LoginStore](https://images.ctfassets.net/23aumh6u8s0i/4M3F4udz68HaJ3KayBDnrm/29757c3eaeacfeabff12f9dcbc7b63fb/pub_w_959_h_638)

The LoginStore, like any other store, has 2 functions:

* It holds the data it gets from the actions. In our case, that data will be used by all components that need to display the user information.
* It inherits from `EventEmmiter`. It’ll emit a change event every time its data changes so that Components can be rendered again.

```jsx
// ... imports
class LoginStore extends BaseStore {

  constructor() {
    // First we register to the Dispatcher to listen for actions.
    this.dispatchToken = AppDispatcher.register(this._registerToActions.bind(this));
    this._user = null;
    this._jwt = null;
  }

  _registerToActions(action) {
    switch(action.actionType) {
      case USER_LOGGED_IN:
        // We get the JWT from the action and save it locally.
        this._jwt = action.jwt;
        // Then we decode it to get the user information.
        this._user = jwt_decode(this._jwt);
        // And we emit a change to all components that are listening.
        // This method is implemented in the `BaseStore`.
        this.emitChange();
        break;
      default:
        break;
    };
  }

  // Just getters for the properties it got from the action.
  get user() {
    return this._user;
  }

  get jwt() {
    return this._jwt;
  }

  isLoggedIn() {
    return !!this._user;
  }
}
export default new LoginStore();
```

> You can take a look at the `BaseStore` [in Github](https://github.com/auth0/react-flux-jwt-authentication-sample/blob/gh-pages/src/stores/BaseStore.js). It includes some utility methods that all stores will have.

### Displaying the user information
#### Creating an Authenticated component
![AuthenticatedComponent](https://images.ctfassets.net/23aumh6u8s0i/5PC7e8aeAH1I1HC3cl4aL0/745651ca250dec79c659d410f5034b47/pub_w_959_h_638)

Now, we can start creating components that require authentication. For that, we’ll create a wrapper (or decorator) component called `AuthenticatedComponent`. It’ll make sure the user is authenticated before displaying its content. If the user isn’t authenticated, it’ll redirect him or her to the Login page. Otherwise, it’ll send the user information to the component it’s wrapping:

```jsx
// ... imports
export default (ComposedComponent) => {
  return class AuthenticatedComponent extends React.Component {

    static willTransitionTo(transition) {
      // This method is called before transitioning to this component. If the user is not logged in, we’ll send him or her to the Login page.
      if (!LoginStore.isLoggedIn()) {
        transition.redirect(‘/login’);
      }
    }

    constructor() {
      this.state = this._getLoginState();
    }

    _getLoginState() {
      return {
        userLoggedIn: LoginStore.isLoggedIn(),
        user: LoginStore.user,
        jwt: LoginStore.jwt
      };
    }

    // Here, we’re subscribing to changes in the LoginStore we created before. Remember that the LoginStore is an EventEmmiter.
    componentDidMount() {
      LoginStore.addChangeListener(this._onChange.bind(this));
    }

    // After any change, we update the component’s state so that it’s rendered again.
    _onChange() {
      this.setState(this._getLoginState());
    }

    componentWillUnmount() {
        LoginStore.removeChangeListener(this._onChange.bind(this));
    }

    render() {
      return (
      <ComposedComponent
        {...this.props}
        user={this.state.user}
        jwt={this.state.jwt}
        userLoggedIn={this.state.userLoggedIn} />
      );
    }
  }
};
```

An interesting pattern is used here.
First, take a look at what we’re exporting. We’re exporting a function that receives a Component as a parameter and then returns a new Component that wraps the one that was sent as an argument.
Next, take a look at the `render` method. There, we’re rendering the Component we received as a parameter. Besides the `props` it should receive, we’re also sending it all the user information so it can use those properties.
Now, let’s create the Home component which will be wrapped by the `AuthenticatedComponent` we’ve just created.

#### Home Page
![Home](https://images.ctfassets.net/23aumh6u8s0i/7nmYef6fXqFBR6O7rMiurQ/78375a59c3a62eec7f8b175c541de511/pub_w_959_h_638)

The `Home` will display user information. As it’s wrapped by the `AuthenticatedComponent`, we can be sure of 2 things:

* Once the `render` method is called on the `Home` component, we know the user is authenticated. Otherwise, the app would have redirected him to the `Login` page.
* We know we’ll have the user information under `props` because we’ve received them from the `AuthenticatedComponent`

```jsx
// ... imports
// We’re wrapping the home with the AuthenticatedComponent
export default AuthenticatedComponent(class Home extends React.Component {
  render() {
     // Here, we display the user information
    return (<h1>Hello {this.props.user.username}</h1>);
  }
});
```

### Let’s call an API!

Now, you should be able to call an API. In order to call an API that requires authentication, you must send the JWT we received on Login in the `Authorization` header. Any `AuthenticatedComponent` has access to this JWT so you can do something as follows:

```jsx
// Home.jsx
// It must be on an AuthenticatedComponent
callApi() {
  fetch(‘http://example.com/my-cool-url', {
    method: ‘GET’,
    headers: {
      Authorization: ‘Bearer ‘ + this.props.jwt
    }
  }
```

### Keeping the user authenticated
Now that the user is authenticated, we want to keep him or her authenticated instead of showing the login page every time he refreshes the website.
Due to the fact we’re saving the JWT on `localStorage` after a successful authentication, we can manually trigger the `LoginAction` and everything will work. That’s the beauty of using Flux.

```js
// app.jsx ==> Bootstrap file
let jwt = localStorage.getItem(‘jwt’);
if (jwt) {
  LoginActions.loginUser(jwt);
}
```

<include src="asides/React" />

## Closing remarks

We’ve finished implementing the Login for a React Flux app. If you want to know how to implement a signup or if you want to see the full example at work, you can [grab the code from Github](https://github.com/auth0/react-flux-jwt-authentication-sample).

Happy Hacking! :).

"dispatcher"