Document Redux Antipatterns

[modernserf]

The documentation covers some common showstopping problems in the troubleshooting chapter, and features many positive examples and links to examples. However, there are fewer examples of antipatterns that, while they may function, are contrary to the design goals of Redux and make things needlessly complicated.

What are some common antipatterns in Redux? And how do we want to cover them in the documentation?

[modernserf]

There are probably many documented antipatterns in these issues already, but here's a more subtle example, that I had struggled with for some time:

Bad:

function userReducer (state, action) {
    switch (action.type) {
    case UPDATE_PROFILE:
            return { ...state, user: action.payload }
    }
}

function notificationReducer (state, action) {
    switch (action.type) {
    case ADD_NOTIFICATION: 
        return { ...state, items: [...state.items, action.payload] }
    }
}

const updateProfile = (data) => (dispatch) => {
    userAPI.loadUser(data).then((user) => {
        dispatch({ type: UPDATE_PROFILE, payload: user })
        dispatch({ 
            type: ADD_NOTIFICATION, 
            payload: "Your profile has been updated." 
        })
    })
} 

Good:

function userReducer (state, action) {
    switch (action.type) {
    case UPDATE_PROFILE:
            return { ...state, user: action.payload }
    }
}

function notificationReducer (state, action) {
    switch (action.type) {
    case UPDATE_PROFILE: 
        return { ...state, 
            items: [...state.items, "Your profile has been updated."] }
    }
}

const updateProfile = (data) => (dispatch) => {
    userAPI.loadUser(data).then((user) => {
        dispatch({ type: UPDATE_PROFILE, payload: user })
    })
} 

The documentation would go on to explain how they differ, why one is preferable over the other, and where responsibilities should fall between action creators and reducers, with links to further reading in the documentation.

[ferdinandsalis]

@modernserf could you explain why its bad practice. My current signup action creator does something similar.

import { AUTH_USER } from 'redux/middleware/auth';
import { pushState } from 'redux-router';
import { setFlash, setErrorFlash } from 'redux/actions/flash';
import { SIGNUP_REQUEST, SIGNUP_SUCCESS, SIGNUP_FAILURE } from 'redux/constants';

export function signup(data) {
  return {
    [AUTH_USER]: { types: [SIGNUP_REQUEST, SIGNUP_SUCCESS, SIGNUP_FAILURE] },
    payload: (client) => client.signup(data)
  };
}

export default function signupUser(data) {
  return dispatch => {
    dispatch(signup(data)).then(action => {
      if (action.type === SIGNUP_SUCCESS) {
        dispatch(pushState(null, '/account'));
        dispatch(setFlash({
          message: 'Yeah, you successfully signed up.',
          kind: 'success'
        }));
      }
    }, err => {
      dispatch(setErrorFlash());
      console.error(err);
    });
  }
}

[gaearon]

I wouldn't actually call that an anti-pattern, it's a fine thing to do in many cases.

[modernserf]

• Redux actions are broadcast to all reducers; ACs should take advantage of this instead of being treated like the API for a single reducer
• ACs are largely a way of formatting data and handling side effects; the lions share of the logic should be in the reducers, not the ACs
• Its much more likely that you will test your reducers than your ACs
• an AC that dispatches another AC couples them together and adds an unnecessary layer of indirection

The "ducks" model (which I was using until I had this revelation) bundles action creators, action types and reducers together, and leads you to the top style -- which works! Plus its more intuitive when you're coming from other event-oriented systems.

But its fighting against Redux's nature: actions are broadcast; every action goes to every reducer. SIGNUP_REQUEST, SIGNUP_SUCCESS and SIGNUP_FAILURE all map to side effects introduced by the user or an AJAX request; they're fairly high-level explanations of things that are happening to your app. ADD_NOTIFICATION is a low-level instruction that doesn't map to any particular action performed by the user or the network.

I recognize that this is largely a matter of taste, but this has helped me wrap my head around the Redux model.

[ferdinandsalis]

@modernserf thanks for clarifying this. Now I understand.

[tomazzaman]

@ferdinandsalis I have a challenge for you, and @gaearon as well - since this appears in the real world example.

Provide a unit test for this piece of code (provided AUTH_USER is a Symbol):

export function signup(data) {
  return {
    [AUTH_USER]: { types: [SIGNUP_REQUEST, SIGNUP_SUCCESS, SIGNUP_FAILURE] },
    payload: (client) => client.signup(data)
  };
}

Requirement: it should run in Karma/PhantomJS

I have wasted spent days on this.

[gaearon]

@tomazzaman

What exactly is it that you want to test here?
That it runs a request given the middleware?
That it correctly describes the request?

I guess running expect on the return values is not what you want, but then you need to explain what you want to test exactly. Here's an example without the middleware: #546 (comment).

Finally, is there a particular problem in using the Symbol? Well, there's no need to use it if you have problems with Symbols! It's just code. Change it how you like. No need to follow examples word by word. ;-)

[gaearon]

For example I'm not sure this is really a helpful test as it's just duplicating the code:

import { AUTH_USER } from '../middleware/api';

let asyncAction = signup(data);
expect(asyncAction[AUTH_USER].types).toEqual([SIGNUP_REQUEST, SIGNUP_SUCCESS, SIGNUP_FAILURE]);

If it's useful, that's the answer to your question. If not, then what you really want to test is either the middleware itself, or middleware executing your particular action.

Here's an example of doing the latter:

import apiMiddleware from '../middleware/api';

function createMockStore(mockState, expectedActions, done) {
  return applyMiddleware(apiMiddleware)(() => {
    getState() {
      return mockState;
    },

    dispatch(action) {
      const expectedAction = expectedActions.shift();
      expect(action).toEqual(expectedAction);

      if (!expectedActions.length) {
        done();
      }
    }
  })();
}

describe('action creators', () => {
  afterEach(() => {
    nock.cleanAll();
  });

  it('creates signup actions', (done) => {
    // mock requests you need in this test
    nock('http://localhost:3000/')
      .get('/signup')
      .reply(200);

    const expectedActions = [
      { type: 'SIGNUP_REQUEST' },
      { type: 'SIGNUP_SUCCESS', payload: { /* ... */ } }
    ];
    const mockState = {
      something: 42
    };

    const mockStore = createMockStore(mockState, expectedActions, done);
    mockStore.dispatch(signup());
  });
});

[gaearon]

PS @tomazzaman please file a separate issue next time because this is unrelated to the topic.
This issue is about anti-patterns, not about testing action creators.

[tomazzaman]

Thanks @gaearon! I have absolutely no experience with Symbols in JavaScript (but use it in Ruby all the time) and that led to console.log( [object with symbol as a key] ) appearing as an empty object in all browsers but Chrome, when in fact, it was not empty which I was able to verify with Object.getOwnPropertySymbols(response); literally minutes after I posted this question. In any case, I'm happy I did, because your example above should definitely be in the Redux testing documentation, so someone else might stumble upon it and thank both of us :)

In truth, I'd prefer all the constants to be Symbols (with Symbol.for('Call API')), because it's easy to access them anywhere, so my unit test looks something like this:

// actions.js
import { CALL_API } from '../middleware/api';

export const AUTH_LOGIN = 'AUTH_LOGIN';
export const AUTH_LOGIN_SUCCESS = 'AUTH_LOGIN_SUCCESS';
export const AUTH_LOGIN_FAILURE = 'AUTH_LOGIN_FAILURE';

export function login( user ) {
  return {
    [CALL_API]: {
      types: [AUTH_LOGIN, AUTH_LOGIN_SUCCESS, AUTH_LOGIN_FAILURE],
      endpoint: 'users/login',
      request: {
        method: 'POST',
        body: user,
      },
    },
  };
}

// actions.spec.js
import { expect } from 'chai';
import { login } from '../../../src/js/actions/authActions.js';

const key = Symbol.for('Call API');

describe.only( 'authActions', () => {
  it( 'should dispatch a proper login action', () => {
    const user = { email: 'peter@klaven', password: 'cityslicka' };
    const response = login( user );
    const value = response[ key ];

    expect( value.types ).to.include(  'AUTH_LOGIN_SUCCESS' );
    expect( value.endpoint ).to.equal( 'users/login' );
  } );
} );

PS: Sorry for abusing this topic, I didn't think my question was a separate topic worthy :) Will do so next time.

[exogen]

It's true that @modernserf's antipattern example is fine to do in many cases, but IMO it's never a bad idea to offer some official guidance with respect to best practices. I realize @gaearon might think this makes Redux seem more opinionated whereas he likes that it's so simple and open-ended – but again, guidance is always good!

(In my own usage I've arrived at the same conclusion as @modernserf – in that example, only one action took place. Adding the notification was a state modification in response to that single action, not a separate action in and of itself.)

[exogen]

I'll add that even if Redux doesn't take a stance one way or the other, merely mentioning both patterns in a FAQ or whatever is going to help a lot of people.

[acstll]

@modernserf thanks for sharing, though in my old vanilla Flux code I had a Notifications store that would react to all kind of actions (just like in your "Good" example), in my recent Redux code I've been making this mistake of having a notify action creator, for example.

I have a question for you. How do you clear up your notifications (or flash messages @ferdinandsalis) after they've showed up?

I have a case where I set a timer inside the notifications component just to hide it… but I'm not sure about that. I would like my notifications to stack inside the store and then be cleared up as they show…