0

I am designing redux actions for a user signup. Signup process requires three entities to be created User, UserProfile and an Offer and involves side effects to handle async server calls.

I wonder what actions should be introduced to make them clear, readable and not overcomplicated. The minimum set of actions I can think of could be

  • User.SIGNUP_START
    • triggered by form submit
    • consumed by UserEffects.signUp
  • User.SESSION_TOKEN
    • dispatched by UserEffects.signUp to indicate session returned by the server
    • consumed by UserReducers to update redux state
  • User.SIGNUP_SUCCESS
    • dispatched by UserEffects.signUp, contains just a reference to the created entity
    • consumed by UserReducers to update redux state
    • consumed by UserEffects.createProfile - here is the first doubt if dedicated UserProfile.CREATE action should be used and how?
  • UserProfile.CREATE_SUCCESS
    • dispatched by UserEffects.createProfile, contains just a reference to the created entity
    • consumed by UserReducers to update redux state
    • consumed by UserEffects.createOffer - same doubt if dedicated Offer.CREATE action should be used and how?
  • Offer.CREATE_SUCCESS
    • dispatched by UserEffects.createOffer, contains just a reference to the created entity
    • consumed by UserReducers to update redux state

To make the above list simple I've skipped *.*_ERROR actions I have in my code.

Main question is - should there be CREATE, CREATE_SUCCESS, CREATE_ERROR set of actions for each async server call or is it ok for Effects to listen just to *.CREATE_SUCCESS to initiate async call to create next entity in the flow?

I'd like to avoid too much boilerplate related to action creators yet I prefer readable design.

NOTES

  • chained async calls are there as I would like to avoid backend code for the time being (the plan is to move directly to GraphQL in the future).
  • as for the terminology I'm using Angular & ngrx/store yet the problem is relevant to any Redux solution.
2

In general, just look for the message that has enough data to be actionable. For example, if a websocket passes a message, add that to the store:

myWebSocket.onmessage = function (event) {
  store.dispatch({ 
  type: 'BLOG_POST_UPDATE_RECEIVED',
  payload: event,
  } 
}

When deciding whether a given piece of state should be in Redux, ask yourself if seeing that state (and the actions that influenced it) could be helpful when debugging issues. If the answer is yes, consider putting that state in Redux so that it will be logged with crash reports and user issues.

We wrote custom middleware that completely abstracts fetching data. Connected components can use our action builders to dispatch REST_API_FETCH actions and then just wait for the results to trickle in as Redux state updates. The middleware will execute the rest call and handle the asynchronous response and any errors.

References

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.