🌳
🌳
🌳
🌳
Walking though the Elm woods
Search…
🌳
🌳
🌳
🌳
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
Making impossible states Impossible
Non empty lists using Zippers
Restrict records using Opaque Types
Write safer functions using Phantom Types
Designing Elm package APIs
🔜
Future topics
Frameworks and packages
elm/parser
mdgriffith/elm-ui
🔜
Future topics
Powered By
GitBook
Making impossible states Impossible
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:
Making impossible states impossible
by Richard Feldman
❗
Example:
Tic Tac Toe
❗
Example:
Subset of {a,b}
❗
Example:
Up to 2 choices of a set
Previous
Reusable views
Next
Non empty lists using Zippers
Last modified
2yr ago
Copy link