🌳
Walking though the Elm woods
  • Introduction
  • Structure of the book
  • Frequently asked questions
    • How can different types share data?
    • How to break Dependency Cycles?
    • How to structure an Elm project?
    • How to turn a Msg into a Cmd Msg?
    • How to update nested Records?
    • What are comparable types?
    • Why are Booleans bad?
    • 🔜Future topics
  • Recipes
    • Writing a Single Page Application
      • Share state across pages
      • Debounced Validation
      • Reusable views
    • Making impossible states Impossible
      • Non empty lists using Zippers
      • Restrict records using Opaque Types
      • Write safer functions using Phantom Types
    • Designing Elm package APIs
      • Create upwards compatible APIs
    • 🔜Future topics
  • Frameworks and packages
    • elm/parser
    • mdgriffith/elm-ui
    • 🔜Future topics
Powered by GitBook
On this page

Was this helpful?

  1. Recipes

Making impossible states Impossible

PreviousReusable viewsNextNon empty lists using Zippers

Last updated 5 years ago

Was this helpful?

A good coding practice in Elm is to define the Model such that impossible states can not occur.

Instead of writing

type alias ServerRequest =
    { Response (Maybe String)
    , Failed (Maybe Error)
    }
    -- There can not be a Response and an Error at the same time.

one can use

type ServerRequest =
    Waiting
    Response String
    Failed Error

In this section we will look at common ways how to avoid impossible states.

Further reading

  • 🎥Video: by Richard Feldman

  • ❗Example:

  • ❗Example:

  • ❗Example:

Making impossible states impossible
Tic Tac Toe
Subset of {a,b}
Up to 2 choices of a set