DEV Community

Tyler Haas
Tyler Haas

Posted on • Edited on

Limiting States

This is a cross post from my blog

Limiting State

State management is hard. This major reason for this is the effects of
combinitorial explosion.
In this article I want explore how we can limit the effects of combinitorial
explosion thus making state easier to manage and our apps simpler.

Modeling State

Most developers spend little time thinking about the possible ways to model
their state. Whatever gets the job done is fine. Right? Lets look at some ways
we could model our state. Lets say we have a toggle component. One
implementation might look like this:

function Toggle() {
  const [on, setOn] = React.useState<boolean>(false)
  return (
    <label aria-label="Toggle">
      <input type="checkbox" checked={on} onClick={() => setOn(on => !on)} />
    </label>
  )
}

This is a pretty simple component that a boolean as state probably works fine
for. But lets suppose our product manager comes to us and says "We only want the
user to be able to toggle when they are logged in". Now our component would look
something like:

interface ToggleProps {
  isLoggedIn: boolean
}

function Toggle({isLoggedIn}) {
  const [on, setOn] = React.useState<boolean>(false)

  function toggleIfLoggedIn() {
    if (isLoggedIn) {
      setOn(on => !on)
    }
  }

  return (
    <label aria-label="Toggle">
      <input type="checkbox" checked={on} onClick={toggleIfLoggedIn} />
    </label>
  )
}

Now we have two pieces of state (props are just passed in state). So the total
possible states we can be in is now 4.

count isLoggedIn on
1 false false
2 false true
3 true false
4 true true

Now lets say that our product manager comes back to us and says: "You know what
lets save whether our toggle is on or off to the database". So we make that
change.

interface ToggleProps {
  isLoggedIn: boolean
}

function Toggle({isLoggedIn}) {
  const [on, setOn] = React.useState<boolean>(false)
  const [error, setError] = React.useState<string>(null)
  const [isLoading, setLoading] = React.useState<boolean>(false)
  const [hasError, setHasError] = React.useState<boolean>(false)

  React.useEffect(() => {
    setLoading(true)
    fetch('apiResource')
      .then(res => res.json())
      .then(data => {
        setLoading(false)
        setOn(data.on)
      })
      .catch(errorResponse => {
        setLoading(false)
        setHasError(true)
        setError(errorResponse)
      })
  }, [])

  function toggleIfLoggedIn() {
    if (isLoggedIn) {
      setOn(on => !on)
    }
  }

  if (isLoading) return <span>Loading...</span>

  if (hasError) return <span>{error}</span>

  return (
    <label aria-label="Toggle">
      <input type="checkbox" checked={on} onClick={toggleIfLoggedIn} />
    </label>
  )
}

now we're getting the explosion of states we were talking about. Here is the
total set of possible states now:

count isLoggedIn on error isLoading hasError
1 false false null false false
2 false false null false true
3 false false null true false
4 false false null true true
5 false false string false false
6 false false string true false
7 false false string true true
8 false false string false true
9 false true null false false
10 false true null false true
11 false true null true false
12 false true null true true
13 false true string false false
14 false true string true false
15 false true string true true
16 false true string false true
17 true false null false false
18 true false null false true
19 true false null true false
20 true false null true true
21 true false string false false
22 true false string true false
23 true false string true true
24 true false string false true
25 true true null false false
26 true true null false true
27 true true null true false
28 true true null true true
29 true true string false false
30 true true string true false
31 true true string true true
32 true true string false true

Yep. 32 possible states for 5 pieces of state. And this is for state that only
has two possible values for each state. We've all seen states that have
significantly more possible values for each piece of state and significantly
more pieces of state. Consider if any one of these was a complex object that has
properties that are nullable. Things get out of hand really quick if you're not
careful in front end development.

A Better Way to Model Your State

looking at the chart above and thinking about what should be possible can get
us a long way in getting to a better data model. For example if we model our
state in such a way that if the user is not logged in then we can't have any of
these other states that reduces our possible states in half. Further should it
be possible to have both an error and loading at the same time? Probably not.
How about having an error message but hasError be false. Turns out that also
doesn't seem reasonable. What if we changed our model to only allow valid
states? What would that do to our possible states?

Lets look at another data model to explore this idea. Imagine we had the
following.

interface Unauthenticated {
  isAuthenticated: false
}

interface Rejected {
  isAuthenticated: true
  hasError: true
  error: string
}

interface Pending {
  isAuthenticated: true
  isLoading: true
}

interface Success {
  isAuthenticated: true
  on: boolean
}

type ToggleState = Unauthenticated | Success | Rejected | Pending

Which would result in the following possible states:

count isLoggedIn on error isLoading hasError
1 false N/A N/A N/A N/A
2 true true N/A N/A N/A
3 true false N/A N/A N/A
4 true N/A string N/A true
5 true N/A N/A true N/A

and thats it! 32 possible states becomes just 5 possible states! Thats less than
1/6th of the possibilities. This is much simpler to comprehend and implement and
because we've modeled it in typescript the compiler will catch any places where
we are doing something that our business logic says shouldn't be possible. This
will result in much simpler and maintainable applications.

Conclusion

By modeling our state correctly we are able to limit the amount of possibilities
we have to hold in our heads and consider and we get better TypeScript support.
This helps us to eliminate bugs while simplifying the business logic so its both
easier to understand and contains less surface area for bugs to creep into our
programs.

Top comments (0)