🗺 Reason Design Patterns

An unofficial collection of "Design Patterns" collected from learning, experimenting, and working with Reason and OCaml.

These "patterns" have worked well for me, but, since experience is subjective, YMMV. They are not infallible, they are 100% not something I invented (but merely rediscovered), and if you have any input please send PRs!

Domain Modeling

If your code says too much about how things are done, fights records and variants, or is plagued by empty lists and booleans that mean special things, take a look at these:

1. Boolean Blindness
2. "Pretend" Modules

Module Design

When you are writing modules and libraries, it's foundational to get some things right. A stable interface that leaks no implementation details, good containment of concerns, and the right amount of flexibility are some of the things to consider.

Find below some patterns to help you write modules:

1. Interface First
2. "Pretend" Modules
3. 1 Module for 1 Thing
4. Interpreter Pattern
5. 100-Named-Args Functions

Error Handling that Scales

1. PolyVariant Error Propagation
2. Rresult's Guide to Custom Error Types