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
- inviato da
-
%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'azioneUserEffects.signUp
dedicata e come?
- inviato da
-
%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'azioneUserProfile.CREATE_SUCCESS
dedicata e come?
- inviato da
-
%codice%
- inviato da
UserEffects.createProfile
, contiene solo un riferimento all'entità creata - consumato da
UserReducers
per 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 &
*.*_ERROR
ancora il problema è rilevante per qualsiasi soluzione Redux.