Skip to content
GitLab
Next
Open
Issue created by Thomas Randolph@thomasrandolph0️⃣Developer

New: Use Finite State Machines

New Pattern Proposal: Use Finite State Machines

Some things - especially components - need to represent state that has no business anywhere outside of the component. We should begin representing this contained state with finite state machines.

Advantages of new pattern

  1. Extremely testable - if code's behavior is fully encapsulated in a finite state machine, we can test that the state updates correctly at every step of any process
  2. Extremely readable - instead of fiddling with a bunch of state booleans, actions that change the state of some code are documented as transition events, like LOAD_SUCCESS. You don't need to know which flags would have been updated there to know what happened.
  3. Extremely declarative - Instead of inferring what state something is in at any moment, there's a single definition of what state is possible - and how to get there and move out of it.
    • State is a single string; it either is something, or it is not. No more checking combinations of flags.

Disadvantages of new pattern

I'm honestly having trouble thinking of a negative, maybe...

  1. There's a bit of extra code - the machine definition is a moderate-sized object
  2. States and Transitions should be extracted to constants, so there will be a bunch of extra constants laying around in modules
  3. It could be confusing to have state (e.g. global state, Vuex) and state machine (e.g. internal state).
    • I must note that these are - obviously - different things. I think most people agree you can and should have both.
  4. Some folks might prefer to deal with clusters of booleans
    • Maybe if( !isLoading && hasError ) is preferable - to some - to if( is( 'errored' ) )
  5. It's an abstraction of something you could do in a few lines of code directly in a component

What is the impact on our existing codebase?

None at all. This is entirely opt-in, and nothing that currently exists has to be touched.

Adding the reference implementation as is will work without modification.
It is 49 lines of code (plus 329 lines of tests).

It's also eminently reversible: since this is entirely self-contained to the (component|module|class) where it's used, you can add or remove it at whim.

Reference implementation

Boy howdy do I have a reference implementation for you!

gitlab-org/gitlab!32365 (merged)

Prior Art

Edited by Thomas Randolph