Yangshun Tay yangshun

The introduction to Reactive Programming you've been missing

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

CSS Layout Debugger

A tweet-sized debugger for visualizing your CSS layouts. Outlines every DOM element on your page a random (valid) CSS hex color.

One-line version to paste in your DevTools

Use $$ if your browser aliases it:

~ 108 byte version

React (Virtual) DOM Terminology

In React's terminology, there are five core types that are important to distinguish:

ReactElement / ReactElement Factory
ReactNode
ReactComponent / ReactComponent Class

React Elements

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

React now supports the use of ES6 classes as an alternative to React.createClass().

React's concept of Mixins, however, doesn't have a corollary when using ES6 classes. This left the community without an established pattern for code that both handles cross-cutting concerns and requires access to Component Life Cycle Methods.

In this gist, @sebmarkbage proposed an alternative pattern to React mixins: decorate components with a wrapping "higher order" component that handles whatever lifecycle methods it needs to and then invokes the wrapped component in its render() method, passing through props.

While a viable solution, this has a few drawbacks:

There's no way for the child component to override functionality defined on the higher order component.

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

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

	#!/bin/sh
	# Redirect output to stderr.
	exec 1>&2
	# enable user input
	exec < /dev/tty

	consoleregexp='console.log'
	# CHECK
	if test $(git diff --cached \| grep $consoleregexp \| wc -l) != 0
	then

	# Atom Cheatsheet.


	# Project Key Bindings.

	- 'cmd-shift-p': open the command palette.
	- 'cmd-p' or 'cmd-t': open the fuzzy finder to find a file.
	- 'cmd-b': look for a file that is already open.
	- 'cmd-shift-b': search the list of files modified and untracked in your project repository.
	- 'ctrl-0': open and focus the the tree view.

	* {
	font-size: 12pt;
	font-family: monospace;
	font-weight: normal;
	font-style: normal;
	text-decoration: none;
	color: black;
	cursor: default;
	}