Analysis of Redux, MobX and BLoC and how they solve the state management problem

This thesis starts defining and dividing an application state in two parts: the ephemeral state and the shared state. Then, it decomposes the state management problem in three subproblems, independently solvable. The first sub-problem is about architecting and defining an application shared state in a predictable and testable way. This is the most known problem and can be solved with patterns like Redux and BLoC. The second sub-problem is about synchronizing the shared state with the UI consistently. Stream components and observer components solve this problem efficiently. The former render the application more flexible but introduce boilerplate and the notion of stream; the latter are simpler but less flexible when the application evolves. The third sub-problem is about sharing information between components. This problem relates to the framework and to the specific context and is solved using components that propagate information automatically. The work continues presenting patterns and approaches used to solve each state management sub-problem. Patterns and approaches are presented from a conceptual point of view before being contextualized in the Flutter framework. The objective of this part is to compose three state management solutions, one for each of the most known approaches: Redux, BLoC and MobX. Composed state management solutions are then compared in term of introduced boilerplate using two applications with different complexity. The first application is relatively small and handles a list of todos. The second application has a higher complexity and handles multiple user biometrics taken from different sources. Solutions are compared with each other and with a baseline determined using the basic features offered by Flutter to handle an application state. Before concluding, an experiment aimed at quantifying the impact of the state management solution on the application performances. What emerges is that solutions based on Bloc and Redux introduce a substantial amount of boilerplate, whereas the solution based on MobX slightly detaches from the baseline thanks to the code generator. Another interesting fact is that the boilerplate added by all the three state management solutions with respect to the baseline is higher in the application with a limited number of lines of code but tends to be amortized with the growth of the application in complexity and size. This conclusion, however, is not supported by a sufficiently large collection of data and should be deeper investigated. To conclude, the impact of the state management solution on the application performance ends to be negligible and constrained to be less than a threshold.

All’inizio di questa tesi si definisce e si divide lo stato di un'applicazione in due parti: lo stato effimero e lo stato condiviso. In seguito, si scompone il problema della gestione dello stato in tre sotto-problemi, risolvibili indipendentemente. Il primo sotto-problema si occupa di definire e strutturare lo stato condiviso di un’applicazione in modo predicibile e testabile. Questo è il sotto-problema più conosciuto e può essere risolto con i pattern Redux e BLoC. Il secondo sotto-problema si occupa di sincronizzare lo stato condiviso con la UI in modo consistente. I componenti a Stream e i componenti osservabili risolvono questo problema in modo efficiente. I primi rendono l’applicazione più flessibile ma introducono anche una discreta quantità di boilerplate e la nozione di stream; i secondi sono più semplici ma meno flessibili quando l’applicazione evolve. Il terzo sotto-problema riguarda la condivisione delle informazioni tra i componenti. Questo problema si relaziona strettamente con il framework e con il contesto specifico ma, generalmente, viene risolto utilizzando dei componenti che propagano l’informazione automaticamente. Il lavoro continua presentando una serie di pattern e approcci che risolvono ciascun sotto-problema. Questi ultimi sono presentati prima da un punto di vista concettuale e poi contestualizzati nel framework Flutter. L’obiettivo di questa parte è di comporre tre soluzioni per la gestione dello stato, una per ognuno degli approcci più conosciuti: Redux, BLoC e MobX. Le soluzioni composte sono poi confrontate in termini di boilerplate aggiunta, utilizzando due applicazioni con complessità differente. La prima è relativamente piccola e gestisce una lista di “todo”. La seconda ha una complessità più elevata e gestisce molteplici biometriche relative all’utente raccolte da diverse fonti. Le soluzioni sono confrontate sia tra di loro, sia con una baseline determinata utilizzando le funzioni base che Flutter offre per la gestione dello stato di un’applicazione. Prima di concludere, il documento descrive un esperimento volto a quantificare l’impatto della soluzione per la gestione dello stato sulle performance dell’applicazione. Quello che emerge è che sia BLoC che Redux introducono una sostanziosa quantità di boilerplate, mentre MobX si discosta leggermente dalla baseline grazie al suo generatore di codice. Un altro fatto interessante è che le tre soluzioni per la gestione dello stato aggiungono una maggiore quantità di boilerplate rispetto alla baseline nell’applicazione con un numero limitato di linee di codice. Tuttavia, la quantità di boilerplate tende ad essere ammortizzata con la crescita della complessità e della grandezza dell’applicazione. Questa osservazione, tuttavia, non è supportata da una collezione di dati abbastanza elevata e andrebbe investigata più a fondo. Concludendo, l’impatto della soluzione per la gestione dello stato sulle performance dell’applicazione risulta trascurabile e limitato a una soglia massima.