Ian Obermiller

Part time hacker, full time dad.

Side-by-side diffs for Mercurial (hg) & icdiff revisited

A while back I told you how to get side-by-side diffs in Mercurial using icdiff. Turns out the author of icdiff has added the --recursive flag to make the tool accept directories and diff the contents of the files within. New setup instructions follow.

1. Install icdiff

Same as before: Download and install icdiff, making sure /usr/local/bin is in your $PATH.

2. Setup Mercurial

Next, lets configure Mercurial so that it knows about icdiff. We’ll also set the default pager for all commands to less. Add the following to your ~/.hgrc.


# extdiff passes two directories to the diff command
# --recursive tells icdiff to treat the two params as directories
# and recursively diff their contents.
# -- line-numbers shows line numbers on both sides
opts.icdiff=--recursive --line-numbers

# Setting the variable LESS is like passing those options to less.
# In this case, -F (quit if fits on screen), and -R (pass through control chars,
# required for color output)
pager = LESS='FR' less
# Use pager for these commands only. Add any commands you use here.
attend = icdiff,diff,status,log

You can now replace diff in your Mercurial commands with icdiff, and it will do a side-by-side diff instead of inline.

3. Aliases (optional)

Finally, since hg icdiff is of course too long, add the following aliases to your ~/.bashrc or ~/.zshrc:

# side-by-side diffs for uncommitted files
alias ic='hg icdiff'

# diff all changes since the base revision, including uncommitted
# (from master if you are using bookmarks, for example)
alias ica='hg icdiff -r .^'

# diff the existing changes, excluding uncommitted
alias ice='hg icdiff --ch .'


Styling Visited Links with Radium and React

Radium is a library for styling React components that I’ve spent a fair amount of development time on over the past few months. Radium uses inline styles exclusively, and there are some things you just can’t do without CSS. Styling :visited links is one of them. Luckily, Radium provides a <Style> component which makes this pretty easy to accomplish.

The <Style> component will render a <style> tag, and will prepend each selector with the specified scopeSelector. We use the name of the component as the class, but you could be extra careful and append a generated string to the class to be certain it won’t conflict.

import {Component} from 'react';
import Radium, {Style} from 'radium';

export default class ListOfLinks extends Component {
  render() {
    return (
      <div className="ListOfLinks">
            a: {
              color: 'black'
            'a:visited': {
              color: '#999'
          <li><a href="http://example1.com">Example 1</a></li>
          <li><a href="http://example2.com">Example 2</a></li>
          <li><a href="http://example3.com">Example 3</a></li>
          <li><a href="http://example4.com">Example 4</a></li>

You’ll notice I also styled normal links, and that was just for convenience. If I style them inline, like <a href="http://example1.com" style={{color: 'blue'}}>Example 1</a>, I’d have to change the value for visited to #999 !important to make it override the inline style.

Remember, the usual caveats of selectors apply to <Style>, so any children of ListOfLinks that render anchor tags will also be affected. For this reason, you should only use <Style> on components that don’t render {this.props.children}.

Other uses for <Style>:

  • Styling user-generated HTML, like in a CMS
  • Styling the body and html tags (since scopeSelector is optional)

Keyboard Shortcuts with React

In many web apps, you want to trigger an action in response to a keypress when a certain component is showing. I ran into this while playing with NuclearMail. Think gmail style “y to archive” kind of shortcuts. So, building with React, we might have a MessageView component, which, when it is showing, we want to respond to the “y” keypress and archive the message. All we need is the keyboardjs library and some decorator glue code:

// KeyBinder.js

var keyboardjs = require('keyboardjs');

module.exports = function decorateWithKeyBinding(ComposedComponent) {
  var displayName =
    ComposedComponent.displayName ||
    ComposedComponent.name ||

  class KeybinderEnhancer extends ComposedComponent {
    bindKey(keyCombo: string, fn: () => void) {
      this._keyBindings = this._keyBindings || [];
      this._keyBindings.push(keyboardjs.on(keyCombo, e => {
        if (['INPUT', 'TEXTAREA'].indexOf(e.target.tagName) >= 0) {

    componentWillUnmount() {
      if (super.componentWillUnmount) {

      if (this._keyBindings) {
        this._keyBindings.forEach(binding => binding.clear());

  KeybinderEnhancer.displayName = `Keybinder(${displayName})`;

  return KeybinderEnhancer;

Notice how we ignore bindings fired when an input or textarea has focus is the target, so we don’t trigger “archive” while you are searching for something with the letter “y”.

Then, decorate your component with @KeyBinder and call this.bindKey in componentWillMount:

class MessageView extends Component {
  componentWillMount() {
    this.bindKey('y', this._archive);

  _archive = () => { ... };

Notice that _archive uses class properties syntax to avoid using bind. You could also make this into a mixin for easier use with createClass style components, or just use the function call syntax instead, MessageView = KeyBinder(MessageView).

Let me know in the comments if you think this would be useful to publish to NPM!

React Pure Render Decorator

If you’ve adopted JavaScript classes when working with React, you may be missing PureRenderMixin. You can emulate it easily using decorators:

var shallowEqual = require('react/lib/shallowEqual');

module.exports = function PureRender(Component) {
  Component.prototype.shouldComponentUpdate = function(nextProps, nextState) {
    return (
      !shallowEqual(this.props, nextProps) ||
      !shallowEqual(this.state, nextState)
  return Component;

Use it with the decorator syntax or just as a wrapper around your component:

class Button extends Component { ... }

Button = PureRender(Button);

The logic is exactly the same as PureRenderMixin. Keep in mind that this could break if/when React’s internals are rearranged, since we are deeply requiring shallowEqual. This hasn’t been published to NPM, but if you’d like to see it drop me a comment. Hopefully a pure rendering decorator will make its way into react-pure-render instead.

Shave 45kb off your production webpack + React build

If you’re building a React app for production using webpack, don’t forget this simple plugin for your production build:

new webpack.DefinePlugin({
  'process.env': {NODE_ENV: '"production"'}

It will replace all instances of process.env.NODE_ENV with the string "production". When used in conjunction with the uglify plugin, all the code in React that is inside a dev only conditional like if ("production" !== process.env.NODE_ENV) { ... } will be stripped.

On my simple app, this shaved 45kb off the production build before gzip. After gzip saved 13.5kb, still not bad. Win!

Conditionally Load Intl Polyfill with Webpack

So, you want to use the new JavaScript Internationalization API, Intl? Perhaps you even want to use it with the awesome React Intl library. Browser support is okay, but if you want to support <IE11 and any version of Safari you’ll have to use a polyfill. Unfortunately, the polyfill is pretty large if you use the full build with all languages, clocking in at ~150k minified and gzipped. Wouldn’t it be great if we could set up our JavaScript app to download the Intl library only if the browser needs the polyfill? Fortunately, this is really easy to do using webpack.

1. Install intl

npm install --save intl

2. Modify app’s entry point

Before,  our app’s entry point using React was simple and synchronous:

var React = require('react');
var App = require('./App');

React.render(<App />, document.body);

Now, we need to put all our initialization code into a function, and wait to invoke the function until the polyfill is loaded:

function run() {
  var React = require('react');
  var App = require('./App');

  React.render(<App />, document.body);

// Check if polyfill required
if (!window.Intl) {
  // Webpack parses the inside of require.ensure at build time to know that intl
  // should be bundled separately. You could get the same effect by passing
  // ['intl'] as the first argument.
  require.ensure([], () => {
    // Ensure only makes sure the module has been downloaded and parsed.
    // Now we actually need to run it to install the polyfill.

    // Carry on
} else {
  // Polyfill wasn't needed, carry on

That’s all there is to it. Webpack takes care of splitting the bundle and downloading the polyfill on require.ensure! This method should work with all kinds of polyfills, and keeps your app lean for modern browsers yet working in the rest. For more information, see the webpack documentation for code splitting.

React Anti-Pattern: Positional Children

When designing reusable components with React, you may need to dig into the children prop, say to wrap each child in another element or change the ordering. Once you’ve done so, you may also be tempted to do different things depending on the index of the child. An example from the Facebook codebase is the <LeftRight> component, which floats one child to the left, and another to the right. Its API looks like this:

  <div>floated to the left</div>
  <div>floated to the right</div>

Instead, simplify the API of <LeftRight> and pass the two children as props instead:

  left={<div>floated to the left</div>}
  right={<div>floated to the right</div>}

The props-based version:

  • Is easier to implement – no mucking about with React.Children
  • Is easier to use, since the API to the component is now explicit
  • Can have better validation, like requiring the props to be of a certain type
  • Is more flexible – what if left wasn’t required?

This post was inspired by spicyj’s comment on a React issue.

Flux Panel at ReactJS Conf 2015

Last week in Menlo Park was the first ReactJS conference, hosted by Facebook. I had the honor of being on the Flux Panel with some amazing developers. Bill Fisher did an excellent job preparing us for the panel and moderating, and it is chock full of nuggets of wisdom from those of us building some of the largest React+Flux apps. Topics include Relay vs Flux, isomorphic apps, maintainability, and approaches to data fetching. (more…)

Side-by-side diffs for Mercurial (hg)

UPDATE: This is easier now! See my new post, “Side-by-side diffs for Mercurial (hg) & icdiff revisited”.

Ever wish for hg diff in side-by-side view? I find it much easier to scan, assuming you have the horizontal real-estate in your terminal. Here is a simple guide to setting up side-by-side diffs in Mercurial on Linux/OSX: (more…)

React and Flux Interview

Andrew Cholakian and Trenton Strong, avid users of React, asked me a few insightful questions about using Flux with React in a large app. The full transcription follows.


Older Posts »