Paulo Ragonha pirelenito

When coming from large frameworks like Backbone, Ember or KnockoutJS, as many of us do, it's easy to get used to the fact that the framework provides a lot of "magic". The abstractions they provide, while extremely useful, are often so opaque that even if you wanted to, understanding how they are implemented is a hard task.

Because of this, it's no surprise that we expect the same thing from Redux. We see methods like combineReducers and concepts like action creators and assume that they are complicated, magical beasts that cannot be understood by mortal folk.

The intention of this post is to refute that by taking a look at the central concept of Redux - the store.

The problem

Every solution has a problem that it attempts to solve. Redux's problem is that application state is often spread out and complicated to reason about. The solution it provides is what it calls a state container - the store.

Can't share the complete code because the app's closed source and still in stealth mode, but here's how I'm using React Router and Redux in a large app with server rendering and code splitting on routes.

Server

Wildcard Express route configures a Redux store for each request and makes an addReducers() callback available to the getComponents() method of each React Router route. Each route is responsible for adding any Redux reducers it needs when it's loaded. (This isn't really necessary on the

Auto-deploying built products to gh-pages with GitHub Actions

This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.

A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:

It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
It is free, with no quotas.
Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.

New React Element Factories and JSX

In React 0.12, we're making a core change to how React.createClass(...) and JSX works.

If you're using JSX in the typical way for all (and only) React components, then this transition will be seamless. Otherwise there are some minor breaking changes described below.

The Problem

After spending many hours trying to get FreeTDS and unixodbc to run on a Mac OS X 10.8 system with the python module, pyodbc, I eventually came to this recipe, which is remarkably simple thanks to homebrew. I also found unixodbc was unnecessary and I couldn't get it to play well with FreeTDS, so this install does not include unixodbc. See also http://www.acloudtree.com/how-to-install-freetds-and-unixodbc-on-osx-using-homebrew-for-use-with-ruby-php-and-perl/ and http://www.cerebralmastication.com/2013/01/installing-debugging-odbc-on-mac-os-x/.

Prerequisites: Be sure you have XCode and the Commandline Tools for XCode installed from Apple. Also install homebrew followed with brew update and brew doctor.

Install FreeTDS:

brew install freetds

Test your install:

	function createDisabledUntilClientRendersComponent(component, displayName='ClientComponent') {
	return React.createClass({

	displayName,

	propTypes: {
	disabled: React.PropTypes.bool
	},

	getInitialState() {

	#!/bin/bash
	SERVER_IP=<MY_SERVER_IP>

	# copy cloud-config.yml to the server
	scp cloud-config.yml core@$SERVER_IP:~/

	# validate cloud-config file
	ssh core@$SERVER_IP "coreos-cloudinit -validate --from-file ~/cloud-config.yml"

	if [[ $? == "0" ]]; then

	source "https://rubygems.org"

	gem 'sprockets'
	gem 'sprockets-sass'
	gem 'sass'
	gem 'compass'
	gem 'bootstrap-sass'
	gem 'handlebars_assets'
	gem 'coffee-script'

	# Simple version using only "find"
	find . -name "node_modules" -type d -prune -exec rm -rf '{}' +