busypeoples

/* 
  Slaying a UI Anti Pattern in ReasonML
  Based on Kris Jenkins original writing.
  http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html
*/
type remoteData 'e 'a =
  | NotAsked
  | Loading
  | Failure 'e
  | Success 'a;

busypeoples

/*
  remote-data ported to ReasonML

  See also https://github.com/krisajenkins/remotedata
  Tools for fetching data from remote sources (incl. HTTP).
 */

type remoteData 'e 'a
  = NotAsked
  | Loading

busypeoples

Phantom types in ReasonML

Introduction

"A phantom type is a parametrised type whose parameters do not all appear on the right-hand side of its definition..." Haskell Wiki, PhantomType

The following write-up is intended as an introduction into using phantom types in ReasonML.

Taking a look at the above definition from the Haskell wiki, it states that phantom types are parametrised types where not all parameters appear on the right-hand side. Let's try to see if we can implement a similar example as in said wiki.

busypeoples

Back To The Basics

Chapter 2: Using Flow

Introduction

Why does it make sense to use FlowType or TypeScript when working with JavaScript? To give an appropriate answer, the best idea would be to build a small game or application to make the benefits clear.

busypeoples

Back To The Basics

Chapter 1: Using Flow

Introduction

Why does it make sense to use FlowType or TypeScript when working with JavaScript? A good approach in answering this question is to build a small game or application to make the benefits clear.

busypeoples

Making Impossible States Impossible in ReasonML

Introduction

If you have already seen Richard Feldman's talk entitled "Making Impossible States Impossible" or have read "Designing with types: Making illegal states unrepresentable" then you can skip the explanations and just head straight to the Reason examples.

This post is intended to display how to model your Reason Application to prevent creating impossible states. The benefits of being able to design a feature in this way include avoiding having to deal with complex test scenarios regarding defined business rules and a clear documentation of what is possible just by looking at the type definition. Long story short, let's see how this all works by implementing an example.

Requirements

busypeoples

/* Slaying a UI Anti Pattern in Reason */

type remoteData 'e 'a =
  | Nothing
  | Loading
  | Failure 'e
  | Success 'a;

type item = {
  userId: int,

busypeoples

// Why the Hipsters Reduce Everything!

// Map implementation

import R from 'ramda'

const map = (f, data) =>
  R.reduce((xs, x) => {
    return [...xs, f(x)]
  }, [], data)

busypeoples

import {
  always,
  equals,
  identity,
  ifElse,
  map,
  partial,
} from 'ramda'

const isObject = input => input !== null && typeof input === 'object'

busypeoples

import {
  alts,
  chan,
  go,
  operations,
  putAsync,
  take,
  takeAsync,
  timeout,
  CLOSED,