Skip to content

210 How Can you Compare State Management Solutions to Evaluate Them?

Jump to bottom
eddiesTime edited this page Jun 1, 2020 · 4 revisions
Contents of the Section

Introduction

To compare different state management solutions, I had to find a scenario in which they can be compared. For this purpose, I have decided to implement each pattern in the same example application.

But this led to another problem: You don’t want to write the application every time from scratch, or to be more precise, rewrite big chunks of the app only to fit in a different SMS.

That is where the principle of orthogonality [22] is useful.

Principle of Orthogonality

This principle emphasizes the benefits of independence or decoupling of components. One of the advantages is that changes in one component do not affect any of the other. So, in this case, if you change the state management solution, it does not affect the other parts of our application.

I have shown how the amount of refactoring can be reduced with the principle of orthogonality.

The next challenge is to find an architecture that follows this principle.

Next Section >

Back to Top

Contents

  1. Introduction
  2. Prerequisites
    1. Flutter under the Hood
    2. What Is State?
    3. How Does Flutter React to State Changes?
    4. State Management
  3. Methodology
    1. How Can you Compare State Management Solutions to Evaluate Them?
    2. Architectural Desicion Process
    3. Domain-Driven-Design
    4. Architecture
    5. The State Management Evaluation App
  4. Results
    1. Principles in State Management Solutions
    2. Implemented Examples
  5. Evaluation
    1. Evaluation Criteria
    2. Evaluation Results
    3. Recommendations
  6. Conclusion
  7. References
Clone this wiki locally