nesbtesh

export function createReducer(initialState, reducerMap) {
    return (state = initialState, action) => {
        const reducer = reducerMap[action.type];

        return reducer
            ? reducer(state, action.payload)
            : state;
    };
}

basarat

[] + []; // JavaScript will give you "" (which makes little sense), TypeScript will error

//
// other things that are nonsensical in JavaScript 
// - don't give a runtime error (making debugging hard)
// - but TypeScript will give a compile time error (making debugging unnecessary)
//
{} + []; // JS : 0, TS Error
[] + {}; // JS : "[object Object]", TS Error  
{} + {}; // JS : NaN, TS Error

gka

thevangelist

import React from 'react';
import { shallow } from 'enzyme';
import MyComponent from '../src/my-component';

const wrapper = shallow(<MyComponent/>);

describe('(Component) MyComponent', () => {
  it('renders without exploding', () => {
    expect(wrapper).to.have.length(1);
  });

andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

Rich-Harris

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.

johnlindquist

import {Component} from 'angular2/core';
import {bootstrap} from 'angular2/platform/browser';
import 'rxjs/Rx';
import {HTTP_PROVIDERS, Http} from 'angular2/http';
@Component({
    selector: 'app',
    template: `
    <ul *ngFor="#person of people | async">
        {{person.name}}
    </ul>    

AndrewRayCode

// based on https://gist.github.com/gre/1650294

// no easing, no acceleration
export function linear( t ) {
    return t;
}

// accelerating from zero velocity
export function easeInQuad( t ) {
    return t * t;

aripalo

#!/bin/bash
# Should be used until https://github.com/webpack/watchpack/pull/23 is merged and available in npm
# See https://github.com/webpack/watchpack/issues/2#issuecomment-135204573 for more info

# Ensure we have npm
if ! hash npm 2>/dev/null; then
  echo 'No NPM installed!'
  exit 1
fi

VaheGrigorian

ParentComponent extends React.Component<{}, {}>{
	static childContextTypes:React.ValidationMap<any> = {
		name: React.PropTypes.string.isRequired
	}
	constructor(props, context){
		super(props, context);
	}
	getChildContext(){
		return {
			name: 'Vahe'