Redux - fromScarso2King - 5 - Le action

Cosa sono le action + formula async 3 + 1

Andrea Simone Porceddu
VLK Studio
5 min readJan 4, 2021

--

Di cosa parliamo in questo articolo?

Dopo aver visto nel dettaglio lo store. Vi parliamo delle action, come sono fatte, come vengono create, quale pattern utilizziamo e quali segreti nascondono.

Disclaimer ☢️

Anche se Umberto Eco non vuole, in questa serie faremo un uso spropositato di un verbo inglese: dispatch. Potremmo tradurlo come “spedire” o “emettere” ma ormai fa parte del gergo quando si parla di Redux, per questo abbiamo deciso di coniugarlo così non ci saranno fraintendimenti:

Io dispatcho, Tu dispatchi, Egli dispatcha, Noi dispatchamo, Voi dispatchate, Essi dispatchano.

Ci siamo tolti un peso, possiamo partire.

Cosa sono le action?

Il concetto di action è super semplice. In termini babbani, si tratta di un messaggio, che tramite il dispatcher viene inviato ai nostri reducer dando indicazioni di come lo stato dovrà essere cambiato (Cambiato non è mai la parola giusta ma la usiamo per comodità).

Tecnicamente non sono altro che delle funzioni che ritornano un oggetto con due proprietà: il type e il payload.

Il type è una stringa, che identifica l’azione. Il payload può avere diversi formati. Nei casi più comuni si tratta di un oggetto che contiene i parametri che l’action passa al reducer quando viene dispatchata, ma può assumere anche la forma di numero, stringa, boolean etc.

Come si dispatcha una action?

Un’ action può essere dispatchata in diversi modi:

  • L’oggetto store mette a disposizione un metodo dispatch, solitamente può capitare quando abbiamo bisogno di inizializzare delle action nei primissimi momenti, dallo start di un’applicazione, oppure è un po più frequente, quando vogliamo dispatchare una action da un thunk.
  • Le action possono essere passate a una componente attraverso l’hoc connect della libreria react-redux che passa alla componente una versione della funzione già wrappata nel dispatch. In realtà anche questo metodo risulta ormai deprecato, in quanto dalle ultime versioni react-redux mette a disposizione dei comodissimi hook.
  • È possibile utilizzare l’hook useDispatch di react-redux . Questo è il metodo più moderno per eseguire il dispatch di una action, e quello che preferiamo.
  • Da dentro il generatore di una saga, è possibile dispatchare una action utilizzando l’effetto put della libreria redux-saga.

Cosa succede quando una action viene dispatchata?

Muore!

No … Non è vero, Il dispatch passa la action al reducer, quando il reducer intercetta una action, esegue una funzione associata ad essa attraverso l’attributo type , questa funzione è detta caseed ha il compito di generare il nuovo stato applicativo attraverso le informazioni presenti nell’attributo payload della action.

Action sync

Le action sincrone sono il caso più semplice. Il giro è quello già spiegato sopra:

  1. Dispatchamo la action verso il reducer
  2. Il reducer restituisce un nuovo stato modificato

Niente magie o conigli dal cilindro, tutto è semplice e lineare; Creare una action sincrona è abbastanza veloce. Vi mostrerò due strade. Uno è metodo classico, già usato all’inizio di questo articolo, l’altro è un approccio che sfrutta l’actionCreator di Redux toolkit.

Action async

Ma cosa accade quando abbiamo bisogno ad esempio di chiamare un server, prima di passare le informazioni al nostro stato?

In questo caso avremo bisogno di interpellare un middleware. Il middleware frequentemente più usato, e anche quello già incluso nel toolkit è thunk, ma noi, come spiegato(e motivato) nella puntata dedicata alle librerie, abbiamo scelto redux-saga.

Approfondiremo questo argomento nell’articolo dedicato ai middleware, e più nel pratico in quello dedicato alle saga.

Per le action asincrone, il numero di action che vanno create sono almeno 3:

  • Una action di request che imposta lo stato di questa parte di stato in una condizione di loading.
  • Una action di success, che viene dispatchata direttamente dal middleware se la chiamata al server va a buon fine, inviando nello stato i dati appena recuperati.
  • Una action di failure, che viene dispatchata dal middleware se la chiamata al server fallisce e solitamente invia l’errore ricevuto nello stato.

In thunk, come abbiamo già detto, uno dei middleware più utilizzati, la prima action che viene dispatchata in realtà, non è una action, ma una funzione asincrona che andrà a sua a volta a chiamare:

  • Una action di request, che setta lo stato di loading in pending per quella parte di stato.
  • Una chiamata al server che restituisce un risultato
  • Una action di success, se la chiamata al server ha esito positivo, o una di fail se il server da picche.

Questa serie mantiene perfettamente il pattern del middleware: La prima action dispatchata non fa nulla a livello di stato, e il reducer cambierà solo con action chiamate dal middleware stesso.

In saga invece non funziona così. Lo stile di programmazione diventa reattivo.

Con redux-saga la prima action che viene dispatchata è davvero una action, con il suo type e il suo payload. Un watcher in attesa di quella action particolare, lancerà immediatamente dopo la funzione asincrona che chiamerà il server e dispatcherà le action che andranno a cambiare lo stato.

forse ora meglio fermarsi! Come già scritto, ci sarà tempo per approfondire tutto questo.

One more thing

Un altra cosa interessante sul createAction del toolkit

Il createAction riceve come argomenti due parametri. Il primo come abbiamo visto è una stringa e si tratta dell’actionType, il secondo invece è una funzione di trasformazione molto utile se abbiamo bisogno di eseguire delle computazioni sul dato prima che questo arrivi al reducer.

Prendiamo un esempio concreto. Alla action viene passata una data in formato estero 2020/12/01, ma il nostro servizio remoto necessita di una data in formato italiano quindi 01/12/2020.

Bene, Possiamo usare la funzione di preparazione per formattare questa data e passarla pronta al reducer.

Continua la serie

Credo che con questa, possiamo passare al prossimo articolo. Parleremo nel dettaglio dei reducer, arriviamo quindi al momento in cui verrà restituito un nuovo stato modificato. Leggilo subito qui!

Qui sotto trovi i link alle altre puntate di questa serie

Fuori serie: 0. Le basi

  1. Il Data Flow
  2. Librerie
  3. Folder Structure
  4. Lo Store
  5. Le Action 👈 tu sei qui!
  6. I Reducer
  7. I Selector
  8. I Middleware
  9. Le Saga
  10. Mini App

--

--