tsnobip

open Belt

let {then, thenResolve, catch, resolve, reject} = module(Promise)

module PgResult = {
  module FieldInfo = {
    type t = private {
      name: string,
      dataTypeId: string,
    }

arnarthor

Reason

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

/** Schema for translations, with @genType for TS/JS usage */
[@genType]
type translations = {
  helloMessage: string,
  helloMessageWithVariable: (~name: string) => string,
};

/** English translations */
[@genType]
let translationsEN = {

jaredly

module StringContext =
  Context.MakePair({
    type t = string;
    let defaultValue = "Awesome";
  });

let component = ReasonReact.statelessComponent("Tree");

let make = _children => {

brampersandon

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"

garybernhardt

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.

jcoglan

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

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 (https://www.npmjs.com/~filamentgroup ).

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

Gulp tasks to use:

dmvaldman

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:

chantastic

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