nicolashery

// We can mentally separate "core state" from "derived state".
// Core state is where you can put normalized data (for relational data):
// it is the "single source of truth".
// Derived state is where you shape the core state into a representation that's
// closer to what you need in your views and components.

var coreState = {
  venuesById: {
    'v1': {id: 'v1', name: 'Hipster Coffee House'},
    'v2': {id: 'v2', name: 'Veggies For Everyone'}

nicolashery

// Flux actions called by views (components) are meant to be "fire and forget":
// the view will get an update after the dispatcher has updated the store.
//
// But sometimes, for view state that only really matters to the mounted
// component (like a loading indicator), it might be simpler to have
// a "done" callback in the action creator. This is considered a Flux
// anti-pattern, but if you don't actually pass data to the callback, you
// make sure not to break the "store = single-source of truth" principle.

// For example, let's say we have a widget that allows the user to add places

nicolashery

/* @flow */

import _ from "lodash";

type UserId = string;

type UserRole =
  'admin' |
  'guest' |
  'member';

nicolashery

# Sexy Bash Prompt, inspired by "Extravagant Zsh Prompt"
# Shamelessly copied from https://github.com/gf3/dotfiles
# Screenshot: http://cloud.gf3.ca/M5rG
# A big thanks to \amethyst on Freenode

if [[ $COLORTERM = gnome-* && $TERM = xterm ]]  && infocmp gnome-256color >/dev/null 2>&1; then export TERM=gnome-256color
elif [[ $TERM != dumb ]] && infocmp xterm-256color >/dev/null 2>&1; then export TERM=xterm-256color
fi

if tput setaf 1 &> /dev/null; then

nicolashery

$ mix deps
* fs 0.9.1 (Hex package) (rebar)
  locked at 0.9.2 (fs)
  ok
* gettext 0.9.0 (Hex package) (mix)
  locked at 0.9.0 (gettext)
  ok
* ranch 1.2.1 (Hex package) (rebar)
  locked at 1.2.1 (ranch)
  ok

nicolashery

{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE OverloadedStrings     #-}
{-# LANGUAGE TemplateHaskell       #-}
{-# LANGUAGE DeriveGeneric         #-}

module Main where

import Data.Monoid ((<>))
import qualified Data.Text as T
import Text.Shakespeare.I18N (mkMessage, renderMessage, RenderMessage())

nicolashery

Instructions

Go to http://astexplorer.net/, select babylon6 as the parser, and babelv6 as the transform option.

Paste in the babel-plugin-react-string.js code in the transform area.

Paste the following example source code:

function profile(props) {

nicolashery

node_modules
dist

nicolashery

CLOSURE_COMPILER_VERSION := 20180101
CLOSURE_COMPILER_URL := http://dl.google.com/closure-compiler/compiler-$(CLOSURE_COMPILER_VERSION).tar.gz

closure-compiler:
  mkdir -p vendor
	curl -o vendor/closure-compiler.tar.gz $(CLOSURE_COMPILER_URL)
	tar -C vendor/ -zxf vendor/closure-compiler.tar.gz
	mv vendor/closure-compiler-v$(CLOSURE_COMPILER_VERSION).jar vendor/closure-compiler.jar
	rm vendor/COPYING vendor/README.md vendor/closure-compiler.tar.gz
  

nicolashery

Emulating "enums" in JSDoc version of TypeScript

Problem

TypeScript has support for type-checking plain JavaScript files, which is very useful if you have an existing JS codebase and you want to test the waters and gradually add types.

There are some limitations in what you can do in JSDoc, but a lot of them can be worked-around by using type-definition files .d.ts (for example in a types/ directory). These files don't generate any JavaScript code, they are just there to provide extra type definitions to the compiler.

One thing you can't do in those .d.ts files though, is use enums. You could define them of course, but you won't get the runtime representation since the files don't generate JS code.