Gestione dello stato dell’applicazione in Angular: observable data service come alternativa a Redux

Ho iniziato a collaborare con un collega su una applicazione in Angular che era già stata strutturata, e con mia sorpresa, invece di trovare Redux, ho trovato invece il pattern “Observable data service“. Vista la dimensione dell’applicazione, che sarebbe un back-office non proprio semplicissimo, ho avuto i miei dubbi, ma abbiamo preferito comunque provare, anche perchè poi migrare a Redux non sarebbe stato proprio un grossissimo problema.

Ma in cosa consiste il pattern “Observable data service” ?

Observable data service

In poche parole, questo pattern è una semplificazione di Redux, se mi permettete di compararli.
In pratica abbiamo un service, che chiameremo store, che:
espone dei metodi che il component può chiamare, che corrisponderebbero alle Action di Redux
– il metodo quando viene chiamato chiama a sua volta la funzione esposta da un “backend service”, il quale ritorna un observable. Quando l’observable emette il risultato (in pratica la response del backend), un BehaviorSubject privato emette i nuovi dati
– il service quindi espone i BehaviorSubject, ma come observable

Quindi in pratica per un component non cambia nulla, è sempre in “ascolto” su degli observable, e invia dei comandi, nel nostro caso eseguendo dei metodi esposti dallo store-service.
Il problema è che non stiamo rispettando la single-responsibility, in quanto lo store fa un sacco di cose, che potrebbe portare a problemi se l’applicazione crescesse, o se lo sviluppatore non fosse veramente attento a non fare errori di progettazione.

Ad esempio:
– cosa succede se espongo direttamente gli observable ritornati dal backend-service? In pratica creerei delle dipendenze, un monolite.
– cosa succede se il metodo esposto dallo store-service ritornasse un valore? potremmo farlo certo, ma creeremmo dipendenze tra le varie parti
– come posso implementare delle chiamate al backend cancellabili (cancellable)? Redux lo faceva per noi, invece qui dobbiamo implementare un switchMap e prenderci carico dei dettagli.
– e inoltre dobbiamo prenderci carico di ricevere ed emettere i nuovi valori, che quando hai relazioni tra gli stream, non è che sia proprio semplice. Redux lo faceva in maniera trasparente per noi. Però sarebbe anche un ottimo metodo per imparare gli operatori rxjs.

Giudizio finale

La mia esperienza è che piccole applicazioni, con sviluppatori esperti, può essere in effetti una soluzione più “economica” rispetto a Redux, perchè si è molto più veloci, c’è molto meno codice da scrivere e layer da mantenere.
Però se l’applicazione è di medie dimensioni, allora sarà una grande dispersione di energie, e vi troverete a reimplementare Redux per sopperire ai limiti del pattern. Questo in pratica quello che ci sta succedendo. Tra l’altro alcuni sviluppatori inesperti hanno provato a modificare il codice e il risultato è che era completamente senza senso e avevano creato parecchie dipendenze e strani bug.

Ti potrebbe anche interessare Consigli su come utilizzare Redux in Angular

Leggo con piacere i commenti o le mail che mi inviate a info@stellarsolutions.it

Risorse aggiuntive

Spero di esservi stato utile e condividete pure la vostra esperienza nei commenti!

Add a Comment

Il tuo indirizzo email non sarà pubblicato.