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.signUpper indicare la sessione restituita dal server - consumato da
User.SESSION_TOKENper aggiornare lo stato di redux
- inviato da
-
%codice%
- inviato da
UserEffects.signUp, contiene solo un riferimento all'entità creata - consumato da
UserReducersper aggiornare lo stato di redux - consumato da
User.SIGNUP_SUCCESS- ecco il primo dubbio se deve essere utilizzata l'azioneUserEffects.signUpdedicata e come?
- inviato da
-
%codice%
- inviato da
UserReducers, contiene solo un riferimento all'entità creata - consumato da
UserEffects.createProfileper aggiornare lo stato di redux - consumato da
UserProfile.CREATE- stesso dubbio se deve essere utilizzata l'azioneUserProfile.CREATE_SUCCESSdedicata e come?
- inviato da
-
%codice%
- inviato da
UserEffects.createProfile, contiene solo un riferimento all'entità creata - consumato da
UserReducersper aggiornare lo stato di redux
- inviato da
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 &
*.*_ERRORancora il problema è rilevante per qualsiasi soluzione Redux.