zenparsing

Observable.prototype[Symbol.asyncIterator] = async function*() {

    function promiseCapability() {
        x = {};
        x.promise = new Promise((a, b) => {
            x.resolve = a;
            x.reject = b;
        });
        return x;
    }

wtfil

/*
 * common react, redux staff here
 */
import {Router, createRoutes} from 'react-router';
import createBrowserHistory from 'history/lib/createBrowserHistory';
import rawRoutes from './routes';
import store from './store';

function mixStoreToRoutes(routes) {
    return routes && routes.map(route => ({

bterlson

Pattern Matching

This is a strawman proposal for adding pattern matching to ECMAScript. Pattern matching is useful for matching a value to some structure in a similar way to destructuring. The primary difference between destructuring and pattern matching are the use cases involved - destructuring is useful for binding pieces out of larger structures whereas pattern matching is useful for mapping a value's structure to data or a set of behaviors. In practice this means that destructuring tends to allow many shapes of data and will do its best to bind something out of it, whereas pattern matching will tend to be more conservative.

Additionally, the power of pattern matching is increased substantially when values are allowed to participate in the pattern matching semantics as a matcher as well as a matchee. This proposal includes the notion of a pattern matching protocol - a symbol method that can be implemented by objects that enables developers to use those values in pattern matching. A common scenario w

Gozala

WTF Flow

[Flow][] static type checker is a wonderful attempt to bring [algebric data types][] to JS. It is still fairly new project and there for has few WTFs that can pull you down the rabbit hole. This document is attempt to document things that may seem like a WTF from the perspective of JS developer who tries to employ static type checker, or in other words, some items on the list may be very subjective & based on the background of the writer.

Polymorphic type that is a function

It is very likely that one will wind up using [Polymorphic functions][] to solve a more general problem. And if you define type alias for such a function you may be puzzled what is the right syntax should be used for such type definition.

Let's start with:

clochix

To switch easily between Node versions on Debian, instead of tools like [nvm](https://github.com/creationix/nvm), you can just use [Debian's native alternatives system](http://www.debian-administration.org/article/91/Using_the_Debian_alternatives_system).

(the following commands require root privilege)
 - download and install the node executables under /usr/local/bin/nodes/…
 - add this binaries to the alternative system:
    update-alternatives --install /usr/bin/node node /usr/bin/nodejs 100
    update-alternatives --install /usr/bin/node node /usr/local/bin/nodes/0.10.38/nodejs 50
 - to switch between versions, just call `update-alternatives --config node`

gokulkrishh

/* 
  ##Device = Desktops
  ##Screen = 1281px to higher resolution desktops
*/

@media (min-width: 1281px) {
  
  /* CSS */
  

nolanlawson

// Promise.all is good for executing many promises at once
Promise.all([
  promise1,
  promise2
]);

// Promise.resolve is good for wrapping synchronous code
Promise.resolve().then(function () {
  if (somethingIsNotRight()) {
    throw new Error("I will be rejected asynchronously!");

andrewk

Good Enough™ Form Validation in React

…specifically React 0.13 using ES6 class syntax

Originally I was implementing the validator as a context, but then I got stung by parent context vs owner context. I'll likely return to the context model when React's context implementation is more final (looks like they're moving towards parent context over owner context, which I'd prefer).

Requirements

• markup must match our existing markup, for UX consistency.
• inputs are re-usable components with an explicit contract -- they are responsponsible for their error display and any required filtering of their value.

ryanflorence

Folder Structure

Please note

While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.

Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.

brianclements

Commit Message Format

This specification is inspired by and supersedes the [AngularJS commit message format][commit-message-format].

We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.

Each commit message consists of a header, a body, and a footer.