Skip to content

Instantly share code, notes, and snippets.



I have heard a lot of complaints about lack of editor integration or flaky editor tooling in the Reason community. At my previous job we had ~3000 modules and ~80k LOC. I'll admit that we were not very vigilant with .rei files or keeping our inter module dependencies really clean so this slowed both bsb and especially reason-language-server down a lot.

In fact so much that people couldn't use reason-language-server anymore on 15" MacBook Pros.

I myself have always used a Merlin based setup since I joined the Reason eco system before reason-language-server, and in our project my setup had never failed. Therefor I went on a quest of setting up 3 of the major editors (Emacs, Vim and VSCode) and documenting how to get them working

elnygren /
Last active Jan 16, 2020
Simple ReasonML i18n internationalization example with strong static typing and JS/TS support with GenType
/** Schema for translations, with @genType for TS/JS usage */
type translations = {
helloMessage: string,
helloMessageWithVariable: (~name: string) => string,
/** English translations */
let translationsEN = {
jaredly /
Last active Jan 1, 2021
ReasonReact Context API Example
module StringContext =
type t = string;
let defaultValue = "Awesome";
let component = ReasonReact.statelessComponent("Tree");
let make = _children => {
skylineproject /
Last active Jan 7, 2019
A quick helper util for getting a misbehaving React Native environment back to normal.
alias clean-rn="watchman watch-del-all && rm -fr $TMPDIR/npm* && rm -rf $TMPDIR/react-* && rm -rf node_modules/ && yarn cache clean && rm -rf ios/build && rm -rf ios/Pods && rm -rf android/.gradle && rm -rf android/.idea && rm -rf android/build && rm -rf android/app/build && rm -rf android/app/app.iml && yarn"
View types.markdown

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

View actor.js
const getAllPropertyNames = require('./get_all_property_names'),
Mutex = require('./mutex')
function actor(object) {
let methods = getAllPropertyNames(object),
mutex = new Mutex(),
wrapper = {}
for (let method of methods) {
if (typeof object[method] !== 'function') continue
scottjehl /
Last active Feb 27, 2021
Notes from Wes Bos's talk on web tooling

Notes from @wesbos's talk:

Our frontend workflow is changing quickly and for good reasons. Tooling for tooling sake is a waste, but don't overlook the utility of modern dev tooling workflows - these are great, useful tools that are letting us improve our workflows in standards-based, forward-looking ways.

Trend: Frontend developers are moving to using package managers (npm) for client-side code (CSS and JS), much like we have been for managing our build tooling itself. I can attest to this being hugely helpful at Filament Group on client-side code, especially now that so many of our projects are on npm ( ).

Yay, another talk that recommends loadCSS for performance. Nice to hear :)

Gulp tasks to use:

dmvaldman /
Last active Oct 30, 2020
Descartes, Berkeley and Functional Reactive Programming

Descartes, Berkeley and Functional Reactive Programming

By @dmvaldman

Functional Reactive Programming (FRP) is generating buzz as an alternative to Object Oriented Programming (OOP) for certain use cases. However, an internet search quickly leads a curious and optimistic reader into the rabbit-hole of monads, functors, and other technical jargon. I’ve since emerged from this dark and lonely place with the realization that these words are mere implementation details, and that the core concepts are far more universal. In fact, the groundwork was laid down many centuries before the first computer, and has more to do with interpretations of reality, than structuring programs. Allow me to explain.

There’s an old thought experiment that goes like this:


View on-jsx.markdown

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't



React has revolutionized the way we write user interfaces. It brings an extremely simple mental model to the authoring of UIs. React-native, react-canvas, and other projects have shown us that this model extends beyond the browser DOM.

I believe that this functional, predictable approach can also revolutionize how we build real-world user interfaces.