How to Avoid Get/Set Actions in Redux

reactiveredux

The point of redux is to decouple "what happened" from "how the state changes" according to Dan, anyway, but I'm having trouble figuring out how to handle side effects without having getters and setters.

Here's where I am now:

User enters email + password and taps "log in"
App fires off { type: "USER/LOGIN", payload: { email, password } }
Middleware sees "USER/LOGIN" and makes an HTTP request
Reducer sees "USER/LOGIN" and updates state to fetching

THIS IS WHERE I GET STUCK

Here's how I'm handing it now, but it feels like I'm doing something wrong:

Response comes back
If we get a user, dispatch { type: "USER/LOAD", payload: { … } }
If we didn't, dispatch { type: "USER/ERROR", payload: { … } }

Is this right?

Best Answer

It's close, but no.

The main problem lies in the way you are initiating the asynchronous action. The handling of the response is completely correct.

Basically, you are firing an action to mean "Do this special other thing", and that is wrong. You should be updating the state to mean "Do this special other thing". Then it can be updated by any action in any situation you need.

User enters email + password and taps "log in"
App fires off { type: "USER/LOGIN", payload: { email, password } }
Reducer sees "USER/LOGIN" and updates state to fetching
Middleware sees state was in "unfetched" and is now in "fetching" and makes an HTTP request

As a further generalization, we have employed a continuation- basically, you store an action on the store state, and fire that in addition. This is kind of a Redux way of doing promise.then().

Related Solutions

Is Redux using a sanitized God object pattern

What is a God object? From Wikipedia:

Most of [a God object containing] program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program, and also provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes God-like (all-knowing and all-encompassing).

The Redux store only contains one data object and only requires 2 or 3 methods. In this respect it's hard to imagine thinking of it as a God object. It is decidedly not "all knowing."

Now if your reducer is not broken up at all, if all of the logic is in one function, then that might qualify but it's a simple matter to break up the reducer into a bunch of smaller pieces to avoid the situation.

Redux LOADING/SUCCESS/ERROR pattern – when using redux-saga

Yes this pattern will apply well with redux saga.

Think of redux saga as just a middleware layer within Redux. Basically when you dispatch an action in your code, redux saga will intercept that action and then can be used to do async things like calling an API or modifying data and calling other actions.

So in the case of your example, when you dispatch GET_FOO_REQUEST you should have a listener setup in your saga for that action. Then the saga function can look like so:

Dispatch action to toggle loading state in redux
Send the API request
- If successful, dispatch GET_FOO_SUCCESS
- If error dispatch, GET_FOO_FAILURE

Then in your reducer for GET_FOO_SUCCESS/FAILURE you should toggle the loading state to off and do whatever else you need.

You can write all the boilerplate code yourself, however one cool library you can use is redux-saga-routines, it will automatically create 5 different action types for this purpose:

routine.TRIGGER
routine.REQUEST
routine.SUCCESS
routine.FAILURE
routine.FULFIL

Here is an example saga using these action types:

function* callAPI(action) {
  yield put(routine.REQUEST());
  try {
    const response = yield call(api, 'GET', '/foo/endpoint');
    yield put(routine.SUCCESS(response.data))

  } catch(err) {
      yield put(routine.FAILURE(err.message));

  } finally {
      yield put(routine.FULFILL());
  }

}

Best Answer

Related Solutions

Is Redux using a sanitized God object pattern

Redux LOADING/SUCCESS/ERROR pattern – when using redux-saga

Related Topic