ebidel

<!-- 
Complete feature detection for ES modules. Covers:

1. Static import: import * from './foo.js';
2. Dynamic import(): import('./foo.js').then(module => {...});

Demo: http://jsbin.com/tilisaledu/1/edit?html,output

Thanks to @_gsathya, @kevincennis, @rauschma, @malyw for the help.
-->

jlongster

3 Gripes With React

I started using React 3.5 years ago, and I still love it. It was such a well-designed solution that not much has changed since then, only superficial stuff like naming. What I learned then is still wholly applicable today because it's such a good idea (although now you can choose from many other libraries). On top of that, we now benefit from an entirely new architecture (fiber) without changing much.

evancz

A vision for data interchange in Elm

How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?

These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.

Literature Review

By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.

jlongster

Head Over Heels for Snapshot Testing

Tests are interesting, because you're trying to test code. But to write tests, you have to write code. Who tests the tests? For tests to be worth it you need to be sure that for each line of code you add, the value being added is more than the liability.

Value > Liability

Because belive me, tests are a liability. First, they are code that

busypeoples

Introduction To Flow

Intended for developers interested in getting started with Flow. At the end of this introduction, you should have a solid understanding of Flow and how to apply it when building an application.

Part 1: Flow Fundamentals For JavaScript Developers

Covers all the basics needed to get started with Flow.

Part 2: Flow Fundamentals For ReactJS Developers

Covers all the basic needed to get started with Flow and ReactJS.

busypeoples

//
// MIT License
//
// Copyright (c) 2018 Ali Sharif
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is

busypeoples

//
// MIT License
//
// Copyright (c) 2018 Ali Sharif
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is

lilactown

/**
 * Making promises
 */
let okPromise = Js.Promise.make((~resolve, ~reject as _) => [@bs] resolve("ok"));

/* Simpler promise creation for static values */
Js.Promise.resolve("easy");

Js.Promise.reject(Invalid_argument("too easy"));

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

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