Giuseppe giuseppeg

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

Install https://github.com/vvo/selenium-standalone and start it.

Then run the test script. babel-node test.js.

Building a Maintainable, Agile Architecture for Realtime, Transactional Apps

A maintainable application architecture requires that the UI only contain the rendering logic and execute queries and mutations against the underlying data model on the server. A maintainable architecture must not contain any logic for composing "app state" on the client as that would necessarily embed business logic in the client. App state should be persisted to the database and the client projection of it should be composed in the mid tier, and refreshed as mutations occur on the server (and after network interruption) for a highly interactive, realtime UX.

With GraphQL we are able to define an easy-to-change application-level data schema on the server that captures the types and relationships in our data, and wiring it to data sources via resolvers that leverage our db's own query language (or data-oriented, uniform service APIs) to resolve client-specified "queries" and "mutations" against the schema.

We use GraphQL to dyn

require-from-twitter

Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.

How to use

Source tweet: https://twitter.com/rauchg/status/712799807073419264

const leftPad = await requireFromTwitter('712799807073419264');

Minimum Viable Async with Node 6

With the release of Node 6.0.0, the surface of code that needs transpilation to use ES6 features has been reduced very dramatically.

This is what my current workflow looks like to set up a minimalistic and fast microservice using micro and async + await.

The promise

Parser

/src/parser/spider_monkey_ast.ml: The type definitions for the AST. Tries to stay very close to ESTree
/src/parser/lexer_flow.mll: The ocamllex lexer logic
/src/parser/parser_flow.ml: The recursive descent JS parser

Inference

/src/typing/type_inference_js.ml: Contains the "entry point" for inference (Function called infer_ast).
/src/typing/statement.ml: Most of the inference logic (runs through the AST and generates the initial constraints)

	const I = x => x
	const K = x => y => x
	const A = f => x => f (x)
	const T = x => f => f (x)
	const W = f => x => f (x) (x)
	const C = f => y => x => f (x) (y)
	const B = f => g => x => f (g (x))
	const S = f => g => x => f (x) (g (x))
	const S_ = f => g => x => f (g (x)) (x)
	const S2 = f => g => h => x => f (g (x)) (h (x))

	var npm = require("npm");
	var fs = require("fs-extra");
	var chokidar = require("chokidar");

	var packagePaths = [
	"../mobile-app/node_modules/shared-package/lib",
	"../web-app/node_modules/shared-package/lib",
	];

	var noop = () => {};


	let rows = {}

	export default function(props = [], state = []) {
	return function(target) {
	const proto = Object.create(target.prototype)

	proto.shouldComponentUpdate = function(newProps, newState) {
	let id = (this._update_id = this._update_id \|\| Math.random())

	/** stuff.css */
	:root {
	--magic: {
	font-size: 3em;
	}
	}

	/** my-component.css */

	/* @define MyComponent */