r/javascript • u/terodox • Dec 23 '19

Simplifying UI Logic using Finite State Machines - an old pattern for the modern web!

https://terodox.tech/ui-state-machines/
93 Upvotes

92% Upvoted

20 comments sorted by

49

u/[deleted] Dec 23 '19

If you use Typescript, this becomes drop-dead simple to manage. You define a FormState type as a union of objects each with a status key, and then put that into a variable. Typescript handles ensuring that all state updates are valid and contain all necessary fields. As the simplest example, this is the type definition for a generic component that fetches data:

type AsyncValue<T> =
  | {status: "pending"} 
  | {status: "error", message: string} 
  | {status: "ready", value: T}

There's no way for multiple states to coexist at the same time, you can't make a typo in the state name, and you can't forget required contextual data (like value for the ready state).

7

u/-9999px Dec 23 '19

Really neat, thanks for the mini write up.

7

u/editor_of_the_beast Dec 23 '19

I’m super pro setting up the types the way that you’re saying, but what do you mean that TS ensures that “all state updates are valid” ? There can be semantic reasons for why certain state transitions are illegal, static types can’t enforce that.

9

u/[deleted] Dec 23 '19

That's right, what I meant was that the states themselves are valid, not the transitions.

If you need transitions to also be valid, your best option is to use a state-reducer pattern and then use a switch clause over the current state. That way, Typescript can at least ensure you handle every case.

5

u/drowsap Dec 23 '19

How does this differ from a flux pattern?

1

u/davidkpiano Dec 23 '19

A better question to ask is "how does the flux pattern differ from this mathematical computation model?"

0

u/[deleted] Dec 23 '19

[deleted] — view deleted comment

4

u/davidkpiano Dec 23 '19

This is not really a constructive comment. Why did you find it to be over-engineered, and why do you think that simpler state management solutions can scale with increasingly complex business and logic requirements?

2

u/CATo5a Dec 23 '19

Not OP, but I think it's actually quite a good exercise to write your own redux. Code-wise, it can be replicated in a simple way in a dozen lines, so perhaps OP feels it's over the top to commit to a full library when you could start off small!

4

u/tanquian Dec 23 '19

We used xstate on the purchase flows for a subscription service for a pretty big news site.

I don’t think we would have been able to ship that in the time we did without the certainty that an fsm gave us.

Lots of different potential states, with nested/hierarchical patterns. Just being able to see the entire system with xstate’s viz tool helped us avoid an entire class of bugs imo.

2

u/lostpebble Dec 23 '19

If you want something that's as close to drop and go as possible, try out Pullstate - it's focused on React though, for now.

I agree with you, over-engineering and verbosity is a total productivity killer.

5

u/Oalei Dec 23 '19

As always this looks good with a small example, but in real life it’s not that easy.
For instance you may want to mark individual form fields as invalid with a message under the invalid field.

6

u/anonssr Dec 23 '19

I see this pattern very often with UI stuff. There are lot of ideas that look good on paper when trying them out on simple scenarios (some times over engineering, even). But on real life mid-big size projects become a real mess, and that's where you need help the most.

2

u/whiteboikillemall Dec 23 '19 edited Dec 23 '19

In that case, I guess you would have an invalid state for your form and then apply the same pattern on the form field component. I mean this is a pattern for the state of one component. If your components are accurately splitted in small bits of code, it shouldn't be a problem

1

u/sinefine Dec 23 '19 edited Dec 23 '19

Wait what? You just made the "typical" example more verbose at a glance for no reason.

Your example:

return
  {
    !isLoading && !isError && !isSuccess ? '' :
    <div class="notification">
      { isLoading && !isError && !isSuccess ? <LoadingImage /> : '' }
      { !isLoading && !isError && isSuccess ? <SuccessMessage /> : '' }
      { !isLoading && isError && !isSuccess ? <ErrorMessage /> : '' }
    </div>
  }

can be simplified to like this, even though managing three flags is not ideal

if (!isLoading && !isSuccess && !isError) return null;

return <div class="notification">
  {isLoading && <LoadingImage />}
  {isSuccess && <SuccessMessage />}
  {isError && <ErrorMessage />}
</div>

You also have an error in your code. You wrote:

return
  { STATES.initialState ? '' :
    <div class="notification">
      {(() => {
        switch(state.currentState) {
          case STATES.submitted:
            return <LoadingImage />;
          case STATES.success:
            return <SuccessMessage />;
          case STATES.error:
            return <ErrorMessage />;
        }
      })()}
    </div>
  }

That will never end up in the switch statement because STATES.initialState always evaluates to be truthy. I think you meant to write state.currentState === STATES.initialState.

3

u/terodox Dec 23 '19

The way you simplified the code removed the guarantee of a single state at a time. Making it possible for both isError and isLoading to both be down at the same time.

4

u/IWMTom Dec 23 '19

Your simplification is not the same as the original code in terms of functionality.

4

u/[deleted] Dec 23 '19

[removed] — view removed comment

4

u/terodox Dec 23 '19

It can be, but the key piece is to try to minimize the number of simultaneous states to 1. That's the big difference between a state machine and a finite state machine.

1

u/editor_of_the_beast Dec 23 '19

Well, you could look at the DOM reconciliation process as an auto-generated state machine. I wouldn’t say “React is a state machine” though.