1

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?

  • 1
    "What are some of you doing?" is a subjective opinion-poll and not an objectively answerable question, and therefore ineligible. Since the rest of your question is at least mostly good, I've just removed it. – DeadMG Jan 7 '17 at 22:17
1

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().

  • Thank you for this. That makes sense. To clarify though: i'm correct in my assumption that there is no good way of getting around something like "USER/LOAD" - so in this case having a "setter" action is appropriate? – drewwyatt Jan 7 '17 at 22:27
  • One more question: how do you typically approach storing an action? Is that something generally made specific to the reducer that needs to store actions or is it better to have a queue that holds onto things like this (so that the middleware can grab the email/password)? – drewwyatt Jan 7 '17 at 22:31
  • 1
    Yes, you will need to fire actions to set the state into fetching/fetched/errored/etc. You can of course use a generic action like { type: "SETLOGINSTATE", state: Fetching, payload: { email, password} }. For storing an action, we typically just set the action on the Redux state. Our continuations are implemented by returning the action to the top-level reducer, which then recurses to reduce it. The intermediate states are never seen by middleware or the outside world. – DeadMG Jan 8 '17 at 11:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.