Vuex: gestire lo stato

Vuex è un'estensione per le applicazioni scritte in Vue che permette di avere quello che gli autori chiamano state management pattern, ovvero un modello per applicazioni a stato centralizzato.

Il modello base di Vue prevede che ciascun componente sia composto dai seguenti blocchi logici:

• lo stato, che rappresenta il contesto dei dati utilizzati dall'applicazione (concretizzato dall'oggetto data);
• la vista, che permette, tramite un mapping dichiarativo, di rappresentare lo stato all'utente tramite un'interfaccia (concretizzata tramite template HTML);
• le azioni, che permettono di modificare lo stato reagendo alle interazioni che gli utenti fanno tramite la vista (concretizzata tramite eventi e metodi).

Per quanto questo modello sia funzionale e permette di avere modularità, esso è particolarmente rigido in applicazioni di una certa entità nelle quali spesso molti componenti condividono e necessitano di modificare un unico stato globale. Vuex permette di isolare questo stato in un'unica entità singleton, a disposizione di qualsiasi componente, a prescindere dal livello di gerarchia nel quale esso si trova.

Vuex, in concreto, è composto da un modello teorico di regole e di best practice da seguire e da una parte di software che funge da estensione di Vue e che permette di implementare il modello teorico con facilità. In questa prima lezione cercheremo di introdurre gli aspetti teorici, fondamentali per capire questo modello, mentre nella lezione successiva implementeremo un'applicazione Vuex da zero.

Stato e store

Il concetto principale di una applicazione Vuex è lo store. Esso rappresenta il contenitore dello stato globale dell'applicazione. Le caratteristiche che rendono gli store funzionali sono principalmente due:

• la reattività: qualsiasi componente che utilizza un dato contenuto nello store viene notificato di eventuali cambi tramite le funzionalità già apprese in Vue;
• l'immutabilità: gli store non sono modificabili direttamente ma solamente tramite delle azioni specifiche, chiamate mutation in modo da garantirne la consistenza e la tracciabilità.

Nonostante lo stato viene reso globale tramite gli store, non è detto che ciascun componente non possa avere anche uno stato locale. Se esistono proprietà strettamente correlate ad un singolo componente, è corretto che esse rimangano locali. Inoltre la natura globale dello store, non limita la modularità in quanto è possibile scomporre lo store in sotto moduli indipendenti.

Mutation

Come abbiamo introdotto prima, lo stato viene alterato tramite le mutation. A loro volta, esse non vengono invocate direttamente ma vengono "committate" in uno store, come se fossero degli eventi che vengono scatenati, tramite il metodo store.commit("mutationName"). Ovviamente, oltre al nome della mutation, se necessario, è possibile passare parametri aggiuntivi.

Il comportamento delle mutation viene definito direttamente all'interno dello store, proprio come se fossero dei listener sull'evento stesso.

Secondo gli sviluppatori di Vuex, è buona pratica quella di definire delle costanti per i nomi delle mutation, in modo da avere maggior controllo sulle invocazioni, per sfruttare eventuali tool di linting e per riuscire ad avere un file contentente la definizione di tutte le mutation disponibili nell'applicazione.

Ulteriore regola suggerita è quella della sincronia. Le funzioni associate alle mutation devono essere sincrone. Una volta committate sullo store esse devono risolversi subito.

Action

Le action sono simile alle mutation, tranne per il fatto che esse possono contenere codice asincrono e che vengono invocate tramite il metodo store.dispatch(actionName). Esse rappresentano un'azione scatanata da un comportamento di un utente e possono corrispondere ad una o più mutation.

Data l'asincronia del loro comportamento, il metodo dispatch ritorna una Promise, in modo da poter gestire correttamente i valori di ritorno.

Seppur a prima vista esse possano sembrare ridondanti rispetto alle mutation, le action sono particolarmente diverse. Eventuali dubbi verranno risolti grazie all'implementazione di una applicazione reale, cosa che avverrà nel prossimo capitolo.