Redux - fromScarso2King - 0 - Le Basi
YASMA — Yet Another State Management Article
Rieccoci!
Scusate la lunga assenza! Mi ero ripromesso qualche mese fa, dopo la pubblicazione di un’articolo perlopiù teorico sull’optimistic ui (leggilo qui se non l’hai fatto), di pubblicare un articolo sulla gestione ottimistica di uno stato Redux, ma la quarantena ha portato con se un inaspettato e sproporzionato aumento delle attività che ha assorbito tutte le mie energie.
A diversi mesi di distanza, mi sono reso conto che l’argomento da trattare è davvero ampio, e deve essere preceduto da alcuni focus sulle strategie di gestione e organizzazione dello stato.
Obbiettivi della mini-guida
Con questa serie ci prefiggiamo l’obbiettivo di creare una guida (in italiano) che possa essere utile sia per chi non abbia mai approfondito la gestione dello stato applicativo con Redux, sia per chi sa già farlo, ma vuole apprendere un nuovo pattern con tips e best practice per organizzare in maniera efficiente, modulare ed estremamente scalabile i propri stati applicativi.
Requisiti per una buona comprensione dei contenuti
Pur partendo dalle basi, per quanto riguarda lo stato applicativo e la sua gestione, questa serie è pensata per sviluppatori con buon basi su Javascript, Typescript e buona conoscenza della libreria React. Nelle prime tuttavia presenteremo i concetti a un livello più alto, quindi potrebbero interessarti anche se questo non è esattamente il tuo stack.
Di cosa parliamo in questa puntata?
In questa puntata zero partiremo dalle basi ed arriveremo ai motivi che rendono necessario utilizzare questo strumento per la gestione dello stato applicativo. Se sai già cos’è e a cosa serve lo stato applicativo, puoi saltare questa puntata e passare direttamente alla seconda.
Le basi
Con Stato Applicativo si intende la condizione in cui si trova l’applicazione in un dato momento e possiamo immaginarlo come una fotografia. Guardandola possiamo capire se l’applicazione sta effettuando una chiamata verso un servizio esterno, in quale pagina si trova l’utente, chi è l’utente che sta usando l’app e così via.
Con Gestione dello stato invece si intende il modo in cui si organizzano i dati nello stato applicativo e come essi interagiscono tra di loro.
In maniera molto semplicistica possiamo affermare che lo stato applicativo è l’ insieme dei dati mentre la gestione dello stato è l’insieme delle logiche che ci permettono di manipolare questi dati.
Facciamo un esempio per chiarire il concetto: supponiamo di entrare su facebook. Nella nostra homepage vedremo un sacco di post, simpatici gattini ed un buongiornissimo kaffè di nostra zia Carmela.
Bene, possiamo pensare allo stato applicativo come all’insieme dei post presenti, alle nostre informazioni personali, delle nostre notifiche, il numero di mi piace dei post ecc.
Ora, vogliamo mettere un bel mi piace al buongiornissimo di nostra zia Carmela. Spolliciamo sul post e vedremo il contatore dei like incrementare.
Wow, ben 14 mi piace! Il nostro stato applicativo è appena cambiato. Prima la nostra fotografia mostrava 13 “mi piace”, ora 14. Qualcosa ha mutato il nostro stato e quel qualcosa è detta state management!
Gestione dello stato
Gestire lo stato in maniera efficiente è il vero motivo di questa serie di articoli, per farlo bisogna affidarsi a tecniche e pattern che ci permettano di mantenere sempre coerente ed organizzata la nostra applicazione.
Prima di analizzare queste tecniche però è giusto capire il perché siano emerse e quali scenari aiutano a gestire.
Un caso reale
Supponiamo di essere ancora nella nostra homepage di facebook, dopo il pollicione a nostra zia ci arriva un messaggio in chat, è la nostra amica Lucia che vuole andare in centro a prendere una birra, vediamo 2 cose cambiare nella nostra pagina:
1. — Il contatore della chat in alto a destra mostra un badge rosso: C’è un messaggio non letto!
2. — In basso a destra si è aperta una finestrella con il messaggio di Lucia.
Leggiamo il messaggio e vediamo che succede:
Appena faccio click con il mouse nel campo di testo per rispondere a Lucia, il badge in alto a destra sparisce!
Mettiamo la maschera da sviluppatore e pensiamo come implementare questo comportamento:
- Arriva il messaggio.. sai cosa? Faccio una bella funzione che chiamerò.. pippo! No dai, non siamo all’INPS, la chiamerò addMessage.
function addMessage(message) {
// Seleziono la chat corretta da aprire (quella con Lucia)
const chatTab = getChatTab(message.threadID);
// Aggiungo alla chat il messaggio ricevuto
chatTab.append(message);
// Ora posso aprire la chat!
chatTab.open();
}Pff… un gioco da ragazzi, ora mi rimane da gestire il contatore… beh dai modifico un po la funzione addMessage, cosa mai potrebbe succedere?
function addMessage(message) {
// Seleziono la chat corretta da aprire (quella con Lucia)
const chatTab = getChatTab(message.threadID);
// Aggiungo alla chat il messaggio ricevuto
chatTab.append(message);
// incremento il contatore
incrementUnreadCounter();
// Quando leggo il messaggio devo decrementare il contatore
chatTab.onFocus(decrementUnreadCounter);
// Ora posso aprire la chat!
chatTab.open();
}Fatto, no? certo che sì se non fosse che NO!
Ci sono tantissime cose che non vanno in questo piccolo snippet di codice, sono sicuro che molti di voi avranno già visto quali orribili scenari possono emergere da questa gestione, ve ne elenco qualcuno:
- La funzione addMessage è orribile, fa troppe cose (incrementa un badge, aggiunge il messaggio in una lista, apre la chat, ma… un caffettino ☕️ no?)
- Che succede se clicco l’input per rispondere (focus nella chat), poi clicco fuori (tolgo il focus) e poi clicco nuovamente? That’s a bug my friend 🐛, il contatore viene decrementato due volte.
- Se invece che schiacciare sulla chat aprissi il messaggio direttamente dalla pagina dei messaggi? dovrei aggiungere altre responsabilità alla funzione addMessage?
Sicuramente potremmo refactorizzare questo codice e fare in modo che funzioni a dovere, ma questo esempio non è stato fatto a caso, il bug della chat e della gestione dei messaggi non letti ha torturato gli sviluppatori di facebook per mesi e mesi, è stato il loro personale millennium bug.
come hanno risolto? con FLUX!
Vedremo in breve Flux nella prossima puntata, successivamente cominceremo a concentrarci su una libreria che deriva da esso detta Redux, che attualmente è lo standard de facto quando si parla di state management in React e non solo.
Concludiamo
Analizzando l’esempio della chat possiamo notare questi problemi:
- Una gestione di quel tipo è molto imperativa, “aggiungi il messaggio qui e la, apri quella chat e non quell’altra, decrementa/incrementa il contatore solo se”
- Non è scalabile, se si aggiunge una nuova funzionalità (la sparo, un altro contatore perché a Mark girava così) dobbiamo modificare la nostra funzione, andando ad aumentare ancora le sue responsabilità (SOLID principles ciao proprio 👋 )
Proviamo ad immaginare una struttura che possa funzionare meglio.
Sarebbe tutto più semplice se avessi una sola lista di messaggi, in quel caso infatti:
- La funzione addMessage andrebbe ad aggiungere il messaggio esclusivamente a questa lista, nient’altro.
- Il contatore (o i contatori) potrebbe far riferimento a questa lista per capire quanti messaggi sono stati letti e quanti no.
- Eventuali altre pagine con all’interno le chat sarebbero sempre coerenti perché la lista è una sola!
Questa è sotto sotto l’idea di Redux, una singola sorgente di verità. Ma cos’è Redux? e Flux? Se non sai rispondere a queste domande, vai alla prossima puntata!
Continua la serie
Qui sotto trovi i link alle altre puntate di questa serie
Fuori serie: 0. Le basi 👈 tu sei qui!
