leostera/reason-design-patterns

🗺 An unofficial collection of "design patterns" for ReScript, Reason, and OCaml

🗺 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

reason-design-patterns's Issues

Improvements on the interpreter pattern

Hello and again, thanks for this repo.
I really liked the interpreter pattern. However, I want to know more, and it is hard to google. Do you have some specific links about blog post that I can read? If you have, probably will be nice to add them to the article.
Also, it seems the syntax is outdated. It does not compile with any recent version of reasonml. Will you consider updating it?

Mention modules with mutually recursive types in "1 module for 1 thing"

I think that adding a mention of mutually recursive types encapsuled in their own module as described in this blogpost in the "1 Module for 1 Thing" article
can be useful as this is a rather common case.

What do you think about this?

private types as a less-verbose substitute for the view pattern

More of a question than an issue, but wasn't sure where else to ask.

Don't private types achieve the semantics you want? An exposed type which cannot be constructed but can be deconstructed. Are you already aware of this and there's some additional value to the view pattern that I don't understand?

Here's some code which demonstrates what I mean: https://reasonml.github.io/en/try.html?rrjsx=true&reason=LYewJgrgNgpgBAVQM4wE4HUCWAXAFgNUxgHcAuOAbwCg45sBPAB3mwG4a6n4A3I4uALyUOtAHYBDYDHJJsqTKIDmAGhFxxi6XAXZVtAL7tasbHGDiA1loAUAPwlSZchSri2NWnQEpBAPjpGcCZwvCTkpgL+ocTs+oLCtAzMdPHUtGKSWrLySnrpHuQ6eYYcSTx8qWoOWc65agXaorocJcYwpuZW8XbVym4eXuF+lL3qmq1B7SF8Q5HTJPER-hTV4QB0ow3Yax4lJVSgkLBwAAry3OLYMMho5GmcyRFqjPIJ6RmOcNkuee8NRWoJsFOjZ7JknDlXO5NIUmj45mwqHEhPcyikUVVwV9aip6jDGs0DIFgZZ4EIepk+tCYIN0ctNuNYuwqMEAPrxM6YC5XG6oNYgilSAQAIikwqpHgEAGYAAxedhs1Kc7nXFB81ZwUUwcVjLSywxAA

How do you deal with identity types that have no validation rules?

Very nice collection of patterns you have here, thanks for sharing. I have been using some of them for some time now and I just discovered your Repository, which is a very nice resource. However there is a little edge case that I didn't find a good way to handle and I didn't saw any way in any of your articles in this repository either. It has to do with types that doesn't have any particular validation rules other than being from a trusted source. My main use case are IDs, to avoid mixing IDs from one entity with IDs of other entities. This IDs doesn't have anything in special, they are all uuids and the only way to know they are correct is by reading them from the DB or doing a round trip to the Db. This all works fine when you are in the core of your app and you just parse the data from the database, however things get tricky when you need to take those IDs from other sources. For example, an incoming Rest request, a CLI input etc. One solution that comes to my mind is to create special serialization formats for those IDs and force clients to use them as I return them, but this may only work for clients that I directly control, and it's probably not going to be very nice to deal with.
How do you approach such scenarios?
Regards

Pretty Printing Values link is broken

This line here https://github.com/ostera/reason-design-patterns/blame/master/README.md#L24