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.
Improve this question

1 Answer 1

Reset to default
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

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.