Comparing ES7 and core.async
ES7 | core.async |
---|---|
async function() {...} |
(fn [] (go ...)) |
await ... |
(<! ...) |
await* or Promise.all(...) |
(doseq [c ...] (<! c)) |
ES7 | core.async |
---|---|
async function() {...} |
(fn [] (go ...)) |
await ... |
(<! ...) |
await* or Promise.all(...) |
(doseq [c ...] (<! c)) |
Note: This is a submission for a Reactive2015 lightning talk. If you'd like to see a lightning talk about this (or read a detailed blog post if you are not going for the conference), vote for it by starring this gist! Thanks a lot!
Performance is one of the reasons why React.js is so popular for building complex, highly interactive web applications. It became the go-to library for developers who don’t like to make compromises for technical reasons when building awesome user experiences. However even with React.js it still can be easy to hit it’s performance limits.
In this lightning talk Daniel will go beyond the basics of shouldComponentUpdate and immutable data structures and will discuss how to correctly instrument, measure and optimize performance in complex React apps. He will help you understand the overhead of different parts of the React component lifecycle, how some of it’
So basically FlowType doesn't know about CSS Modules, a really handy way of dealing with the plagues of CSS in codebases (global variables and dependency wackiness mainly).
What WebPack allows us to do is "require" CSS files and use their class names:
import styles from "my_styles.css";
import React from "react";
#!/bin/bash | |
# Configuration | |
#export DIGITALOCEAN_ACCESS_TOKEN= # Digital Ocean Token (mandatory to provide) | |
export DIGITALOCEAN_SIZE=512mb # default | |
export DIGITALOCEAN_REGION=nyc3 # default | |
export DIGITALOCEAN_PRIVATE_NETWORKING=true # default=false | |
#export DIGITALOCEAN_IMAGE="ubuntu-15-04-x64" # default | |
# For other settings see defaults in https://docs.docker.com/machine/drivers/digital-ocean/ |
(ns xlife | |
(:require [net.cgrand.xforms :as x])) | |
;; xforms is a library of transducers | |
(defn xstep [cells] | |
(into #{} | |
(comp | |
; a comprenhension to generate neighbours | |
(x/for [[x y] % |
version: '3' | |
services: | |
# FRONT | |
chronograf: | |
# Full tag list: https://hub.docker.com/r/library/chronograf/tags/ | |
image: chronograf | |
deploy: | |
replicas: 1 | |
placement: | |
constraints: |
Checkout ClojureScript master and cd to the top of the checkout tree.
Assuming you know it is broken on master but worked in 1.9.562, and there is an easy test you can do right in the REPL.
Run these three commands in your shell:
git bisect start
git bisect bad HEAD
git bisect good r1.9.562
node_modules |
The dependency matrix shows the strength of coupling at a var-by-var level between namespaces.
If you pull the CSV output into a spreadsheet, the numbers in the cells show how many var->var dependencies there are between the namespaces.
If you want to just look at namespace->namespace dependencies (e.g., to create a visualization) then just consider any cell > 0 as a dependency.