As an architect I’m regularly involved in code reviews. One of the lessons I learned from reviewing so many codebases is that most codebases start quite well-defined and clean. It is only after an accumulating set of changes that the code evolves to a mess and turns into spaghetti.
One of the parts of every system that is impacted the most by changes is the user interfaces. What started as a simple set of UI components evolves quite fast to an always growing set of changing conditions that impact the UI state.
An example: an original requirement stating that a ‘Save’ button is disabled until all required fields are entered in a form evolves to a combination of AND all required fields are filled in AND a user has a certain role AND there is no application error AND we are not loading some data AND…
What typically also starts to happen is that the same conditions start to come back in multiple places. Your UI becomes harder and harder to test and you get more complex bugs that are harder to fix.
The solution?
A possible solution is to start modelling your UI’s as a finite state machine (FSM). FSM is an architectural design pattern that describes the application behavior as a finite set of states and actions. For every state is described which state comes next when an action is performed. Just like user flows, these finite state machines can be visualized in a clear and unambiguous way.
For example, here is the state transition diagram describing the FSM of a traffic light:
A state machine can be really helpful when modelling our UI logic: for every action, there is a reaction in the form of a state change.
Sounds interesting? Have a look at the following video by David Khourshid to get a really good explanation: