🗺 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
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.
- Smart Constructors, to give your types additional refinements that can only be done at runtime
- 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:
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:
- Interface First
- "Pretend" Modules
- 1 Module for 1 Thing
- Interpreter Pattern
- 100-Named-Args Functions
- Private Types
Error Handling that Scales
Examples
- smart-constructors
- constructor-views
- boolean-blindness
- providing-evidence
- interface-first
- pretend-modules
- interface-first
- one-module-one-thing
- 100-named-args-functions
- private-types
- interpreter-pattern
To run examples:
npm install
npm start