In Elm, modeling data accurately is more valuable than writing good algorithms.
With clear data modeling, errors that are possible in your program will be fewer, and your codebase more coherent. But doing it well can be a hard skill to develop!
Try to form these habits:
Some data is only present in a particular case.
If our type is
Fish has no
Feathers, and a
Bird has no
Scales. These constraints are possible in Elm!
Use custom types to include conditional data only when needed.
Since all cases must be handled explicitly,
Maybes can multiply the conditions to handle and make your code hard to work with.
When nullable data starts accumulating, consider a custom type to create guarantees.
You may be used to using
Strings in other languages.
Strings don’t constrain possible values enough.
Bools are not descriptive, and they won’t allow for the addition of further options if they come up.
Type variables can be helpful abstraction tools. But does your custom type really need to allow for any possible type to be used?
Try starting from a more constrained set first, and use a type variable only if it’s necessary.
Given a domain concept, how many ways could you model it, and with what other data types?
In Elm, refactoring is aided by the compiler! Change your model, and see how different attempts can make your code easier or harder to work with.