Building UIs with Statecharts

@mukeshsoni

reactjs bangalore meetup #34

Building UIs is hard

Maintaining UIs - even harder

UI code is

  • Buggier than most other types of programs
  • Difficult to test
    • What should we test? Just the happy paths?
    • Are snapshot tests enough?
  • Difficult to enhance
    • Code quality keeps deteriorating with each enhancement

How we code UIs

Bottom up - No high level design

How we code UIs

Thinking in React

Just draw boxes around UI components!

 

Only takes you so far!

https://reactjs.org/docs/thinking-in-react.html

Event-action paradigm

  • There is a user event -> take a series of actions
  • the actions to be executed in response to that event can vary, depending on the previous interactions the user had with other UI objects

  • the action against an event can depend on the state of other UI objects

  • Start by writing simple event handler

  • Make them progressively complex to handle various contexts
  • Results in complex web of interrelated event handlers
  • The context is not evident from the code​
    • If(x < y && z > x && loggedIn && (otherObjectVisible || this otherObjectVisible))
  • No one wants to touch that code again
    • Let's rewrite the component!

Event-action paradigm consequences

if-else-hell

https://github.com/mukeshsoni/react-telephone-input

if-else-hell

Source: Are statecharts the next big UI paradigm? by Luca Matteis

Url: https://www.slideshare.net/lmatteis/are-statecharts-the-next-big-ui-paradigm

Source: Are statecharts the next big UI paradigm? by Luca Matteis

Url: https://www.slideshare.net/lmatteis/are-statecharts-the-next-big-ui-paradigm

Alternative approach - Top down thinking

Finite Automata

Finite state machines

  • Abstract machine with finite number of states
  • Finite number of inputs/events
  • Initial state
  • Is only in one state at a time*
  • State transition on event
  • Deterministic - given a state and an event, transition always returns the same nextState

https://en.wikipedia.org/wiki/Finite-state_machine

https://css-tricks.com/robust-react-user-interfaces-with-finite-state-machines/

We all implement an ad-hoc FSM in our UI code!

Problems with FSM

  • State explosion
  • Event explosion
  • Duplicated states and events
  • Does not scale well with increasing complexity
  • Not readable for even medium com

CD player with FSM

Source - Constructing the User interface with statecharts by Ian Horrocks

Statecharts

Invented by David Harel in 1987

  • Hierarchical states - concept of depth
  • Parallel/concurrent states
  • History
    • ​Specially useful in conjunction with hierarchical states
  • Conditionals
    • ​Allow multiple transitions from one state, for same event
  • Transient states

CD player with statecharts

Source - Constructing the User interface with statecharts by Ian Horrocks

CD player with FSM

Source - Constructing the User interface with statecharts by Ian Horrocks

Rich text editor - FSM

Source - Constructing the User interface with statecharts by Ian Horrocks

Parallel states

Source - Constructing the User interface with statecharts by Ian Horrocks

Representing statecharts with xstate

xstate - https://github.com/davidkpiano/xstate

Statecharts in React

If we are in state S and the event E occurs, we should perform the actions A and make a transition to the state S'.

Erlang FSM Design Principles

http://erlang.org/documentation/doc-4.8.2/doc/design_principles/fsm.html

https://github.com/mukeshsoni/statechart-calculator/

Advantages

  • Well defined semantics to capture the UI
  • No ambiguity in specification
  • Easy to extend/enhance
  • Making impossible states impossible
  • Automatic integration test generation - since the statechart is just a graph
  • Automatic code generation
  • Much better analytics**

Practical tips

  • Think in terms high level design for your code
    • Don't get bogged down by implementation details
  • Resist the urge to code for as long as possible, when you are designing the statechart
    • statechart-coding cycle should be iterative
  • Start with FSM and then refactor to statecharts
    • Figure out higher level states and parallel states

Limitations

  • Higher upfront cost
  • Might not see anything on screen for some time
    • ​Build little bit of statechart, code it. rinse and repeat
  • ​Not suitable for all use cases
  • Might get complicated if higher level states and parallel states not correctly identified
    • Essentially turns into an FSM
  • Limitations of visualisation tools

Mars Curiosity Rover - NASA

https://www.popularmechanics.com/space/moon-mars/a19564346/nasas-curiosity-rover-hits-2000-sol-martian-day-milestone/

https://blog.nomagic.com/statechart-autocoding-curiosity-rover/

  • Auto-maneuver (Cruise phase)
  • Spacecraft Modes (Configures the spacecraft)
  • Launch mode
  • Cruise mode
  • Entry
  • Descent
  • Landing
  • Rover mode

Resources

Thank you!

Made with Slides.com