vidaaudrey

module.exports = {
  entry: './src/js/entry.js',
  output: {
    filename: 'dist/bundle.js'
  },
  module: {
    preLoaders: [{
      test: /\.jsx?$/,
      exclude: /(node_modules|bower_components)/,
      loader: 'source-map'

vidaaudrey

function getEntrySources(sources) {
  if (process.env.NODE_ENV !== 'production') {
    sources.push('webpack-dev-server/client?http://localhost:8080');
    sources.push('webpack/hot/only-dev-server');
  }
  return sources;
}

module.exports = {
  entry: getEntrySources(['./src/js/entry.js']),

vidaaudrey

class LiveView extends React.Component {
  render () {
    const { contributor } = this.props;
    return (
      <div>
        <h1>Hello {contributor.name}!</h1>
          {contributor.novels.edges.map(edge => (
            <Novel key={edge.node.id} novel={edge.node}/>
          ))}
      </div>

vidaaudrey

{
  // http://eslint.org/docs/rules/

  "ecmaFeatures": {
    "arrowFunctions": false,                    // enable arrow functions
    "binaryLiterals": false,                    // enable binary literals
    "blockBindings": false,                     // enable let and const (aka block bindings)
    "classes": false,                           // enable classes
    "defaultParams": false,                     // enable default function parameters
    "destructuring": false,                     // enable destructuring

vidaaudrey

{
  "env": {
    "browser": true,
    "node": true,
    "es6": true
  },

  "plugins": ["react"],

  "ecmaFeatures": {

vidaaudrey

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:

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

vidaaudrey

2015-01-29 Unofficial Relay FAQ

Compilation of questions and answers about Relay from React.js Conf.

Disclaimer: I work on Relay at Facebook. Relay is a complex system on which we're iterating aggressively. I'll do my best here to provide accurate, useful answers, but the details are subject to change. I may also be wrong. Feedback and additional questions are welcome.

What is Relay?

Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).

vidaaudrey

IE6 Only
==================
_selector {...}

IE6 & IE7
==================
*html or { _property: }

IE7 Only
==================

vidaaudrey

const isEmpty = value => value === undefined || value === null || value === '';
const join = (rules) => (value, data) => rules.map(rule => rule(value, data)).filter(error => !!error)[0 /* first error */ ];

export function email(value) {
  // Let's not start a debate on email regex. This is just for an example app!
  if (!isEmpty(value) && !/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i.test(value)) {
    return 'Invalid email address';
  }
}

vidaaudrey

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

var Article = require('../../../models/article');

Those suck for maintenance and they're ugly.

Possible solutions