come progettare azioni redux con effetti collaterali concatenati?

0

Sto progettando azioni redux per l'iscrizione di un utente. Il processo di registrazione richiede la creazione di tre entità User , UserProfile e Offer e comporta effetti collaterali per gestire le chiamate al server asincrono.

Mi chiedo quali azioni dovrebbero essere introdotte per renderle chiare, leggibili e non eccessivamente complicate. Il set minimo di azioni che posso pensare potrebbe essere

  • %codice%
    • attivato dal modulo di invio
    • consumato da User.SIGNUP_START
  • %codice%
    • inviato da UserEffects.signUp per indicare la sessione restituita dal server
    • consumato da User.SESSION_TOKEN per aggiornare lo stato di redux
  • %codice%
    • inviato da UserEffects.signUp , contiene solo un riferimento all'entità creata
    • consumato da UserReducers per aggiornare lo stato di redux
    • consumato da User.SIGNUP_SUCCESS - ecco il primo dubbio se deve essere utilizzata l'azione UserEffects.signUp dedicata e come?
  • %codice%
    • inviato da UserReducers , contiene solo un riferimento all'entità creata
    • consumato da UserEffects.createProfile per aggiornare lo stato di redux
    • consumato da UserProfile.CREATE - stesso dubbio se deve essere utilizzata l'azione UserProfile.CREATE_SUCCESS dedicata e come?
  • %codice%
    • inviato da UserEffects.createProfile , contiene solo un riferimento all'entità creata
    • consumato da UserReducers per aggiornare lo stato di redux

Per rendere semplice l'elenco precedente ho saltato UserEffects.createOffer azioni che ho nel mio codice.

La domanda principale è - dovrebbe esserci Offer.CREATE , Offer.CREATE_SUCCESS , UserEffects.createOffer set di azioni per ogni chiamata al server asincrono o è ok per gli effetti ascoltare solo a UserReducers per avviare una chiamata asincrona per creare l'entità successiva nel flusso?

Vorrei evitare un numero eccessivo di regole relative ai creatori di azioni, ma preferisco il design leggibile.

NOTE

  • le chiamate asincrone concatenate ci sono come vorrei evitare il codice di backend per il momento (il piano è di passare direttamente a GraphQL in futuro).
  • come per la terminologia che sto usando Angolare & *.*_ERROR ancora il problema è rilevante per qualsiasi soluzione Redux.
posta ciekawy 23.02.2018 - 23:28
fonte

1 risposta

2

In generale, cerca il messaggio che ha abbastanza dati per essere attuabile. Ad esempio, se un websocket passa un messaggio, aggiungilo allo 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.

Riferimenti

risposta data 26.03.2018 - 23:37
fonte

Leggi altre domande sui tag