One of the selling points of Elm is that you cannot get null errors. Maybe is
what allows Elm to avoid this billion-dollar problem entirely. It's a beautiful
solution.
But it doesn't take too long before your code is one long ugly nested case
statement checking Maybes at every level. Surely this can't be right. There must
be a better way.
We have an array of tools at our disposal to solve this problem, from simple
convenience functions all the way to eliminating Maybe altogether in favor of
other constructs. Join me on a whirlwind tour of these solutions and take back
control of your codebase.
This talk is aimed more at the beginner/intermediate crowd. I've often been
asked to help clean up deeply nested Maybe code. There are three broad
approaches to dealing with code that's been taken over by Maybe:
- Use utility functions like
mapandandThento eliminate case statements - Decouple the parts of your app that process values from those that handle optionality.
- Choose to model the situation using some other constructs. Data that has
multiple shapes if usually better modeled with union types than
Maybes.
The goal of this talk is to help people confidently use Maybe while preventing
it from taking over the whole codebase.