🗺 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!

If you've found this content useful, considering ordering a copy my book: Practical ReScript

Project Layout

1. Yawaramin's Modular Project Structure

Working with Types

Whether you are modeling TODO lists or mission-critical stuff, these patterns should help you build types that are safe to use, refactor, and evolve.

1. Smart Constructors, to give your types additional refinements that can only be done at runtime
2. Constructor + View, to keep your types abstract without losing pattern-matching

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
6. Private Types

Error Handling that Scales

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

Examples

1. smart-constructors
2. constructor-views
3. boolean-blindness
4. providing-evidence
5. interface-first
6. pretend-modules
7. interface-first
8. one-module-one-thing
9. 100-named-args-functions
10. private-types
11. interpreter-pattern

To run examples:

npm install
npm start