How to fire AJAX calls in response to the state changes with Redux?

Question

I'm converting an existing state model to Redux and it has been painless for the most part. However the one point I'm having trouble with is converting "observed" state ajax requests. Essentially, I have certain ajax requests "linked" to other pieces of state, so no matter who modifies them they'll always be issued correctly. I can get similar behavior by subscribing to the Redux store updates, but firing actions in the listener feels like a hack.

A possible solution is to move logic to the action creator via the thunk pattern. Problem is that I'd either have to duplicate fetching logic across actions (since multiple actions could modify "observed" state), or pull most reducer logic to the action creator level. The action creator also shouldn't be aware of how the reducers will respond to issued actions.

I could batch "sub-actions" so I only need to place the appropriate fetching logic in each action "block", but this seems to violate the concept of actions producing a valid state. I'd rather have this liability at the action creator level.

Are there any generally accepted rules surrounding this? This is not a simple application where ad hoc ajax requests are made as components are interacted with, most data is shared between multiple components and requests are optimized and fetched in reaction to state change.

TLDR; I want to fire ajax requests in response to changes in state, not when a specific action happens. Is there a better, "Redux specific" way of organizing action/actionCreators to mock this behavior, other than firing these actions in a subscribe listener?

Answer 1

Using store.subscribe()

The easiest way is to simply use store.subscribe() method:

let prevState
store.subscribe(() => {
  let state = store.getState()

  if (state.something !== prevState.something) {
    store.dispatch(something())
  }

  prevState = state
})

You can write a custom abstraction that lets you register conditions for side effects so they are expressed more declaratively.

Using Redux Loop

You might want to look at Redux Loop which let you describe effects (such as AJAX) calls together with state updates in your reducers.

This way you can “return” those effects in response to certain actions just like you currently return the next state:

export default function reducer(state, action) {
  switch (action.type) {
    case 'LOADING_START':
      return loop(
        { ...state, loading: true },
        Effects.promise(fetchDetails, action.payload.id)
      );

    case 'LOADING_SUCCESS':
      return {
        ...state,
        loading: false,
        details: action.payload
      };

This approach is inspired by the Elm Architecture.

Using Redux Saga

You can also use Redux Saga that lets you write long-running processes (“sagas”) that can take actions, perform some asynchronous work, and put result actions to the store. Sagas watch specific actions rather than state updates which is not what you asked for, but I figured I’d still mention them just in case. They work great for complicated async control flow and concurrency.

function* fetchUser(action) {
   try {
      const user = yield call(Api.fetchUser, action.payload.userId);
      yield put({type: "USER_FETCH_SUCCEEDED", user: user});
   } catch (e) {
      yield put({type: "USER_FETCH_FAILED",message: e.message});
   }
}

function* mySaga() {
  yield* takeEvery("USER_FETCH_REQUESTED", fetchUser);
}

 No One True Way

All these options have different tradeoffs. Sometimes people use one or two, or even all three of them, depending on what turns out to be most convenient for testing and describing the necessary logic. I encourage you to try all three and pick what works best for your use case.

Answer 2

You can use a middleware to fire up your remote actions in response to the local action.

Let say I have a local action:

const updateField = (val) => {
  {type: UPDATE_FIELD, val}
}

And a input field with:

<input type='text' onChange={this.props.updateField.bind(this.val)}>

So in a nutshell when you type inside of the field it fires your action that in turn changes the state via reducer. Lets just forget how this action was passed to the component or what this.val is - we just assume this has been already solved and it is working.

All is fine about this setup but it only changes your state locally. To update the server you will have to fire another action. Lets build it:

const updateFieldOnServer = (val) => {
  return (dispatch) => {
    MAKE_AJAX.done(
      FIRE_SOME_ACTIONS_ON_SUCCESS
    ).failure(
      FIRE_SOME_ACTIONS_ON_FAILURE
    )
  }
} 

This is just an simple thunk async action thats somehow makes ajax request, returns promises and does something else on success or failure.

So the problem we have now is that I want both of this actions to be fired when I change the state of my input but I can't have the onChange to take two functions. So I will create a middleware named ServerUpdatesMiddleware

import _ from 'lodash'
import {
  UPDATE_FIELD,
} from 'actionsPath'

export default ({ dispatch }) => next => action => {
  if(_.includes([UPDATE_FIELD], action.type)){
    switch(action.type){
      case UPDATE_FIELD:
        dispatch(updateFieldOnServer(action.val))
    }
  }
  return next(action)
}

I can add it to my stack:

import ServerUpdatesMiddleware from 'pathToMe'

const createStoreWithMiddleware = applyMiddleware(
  ServerUpdatesMiddleware,
  thunkMiddleware,
  logger
)(createStore);

And right now every single time when updateField action will be dispatched It will automatically dispatch updateFieldOnServer action.

This is just example I think will describe the problem easily - this problem can be fixed in many other different ways but I think it nicely fits the requirements. It is just how I do things - hope it will help you.

I am using middlewares all the time and have many of them - never had any problem with this approach and it simplifies the application logic - you only have to look in a single place to find out whats going on.

Answer 3

Having modules that subscribe to the state updates and the launch Ajax requests (firing actions as they go) seems fine to me, since it puts the stores/reducers firmly in charge of triggering requests. In my large app, ALL Ajax requests and other async behaviours are done this way, so all actions can be just payloads, with no concept of 'action creators'.

If possible, avoid cascading sync actions. My async handlers never fire actions synchronously, but only once the request completes.

In my view, this is a much more functional approach than async action creators, which you may or may not prefer!

Answer 4

componentWillReceiveProps of react life cycle is the best place to do this. componentWillReceiveProps will be passed both new and old props and inside that you can check for the change and dispatch your action which in turn will fire the ajax call.

But the catch here is state object for which you are checking needs to be added as component's props via mapStateToProps, so that it gets passed to componentWillReceiveProps. Hope it helps!