• setState() is asynchronous.
• SyntheticEvent cannot be accessed asynchronously.

Problems Using event.target Within setState()

I came across an unexpected console error and warning when attempting to use event.target within setState().

Uncaught TypeError: Cannot read property 'value' of null  

Warning: This synthetic event is reused for performance reasons. If you're seeing this, you're accessing the property 'target' on a released/nullified synthetic event. This is set to null. If you must keep the original synthetic event around, use event.persist().  

An example of the code I was attempting to run was:
(Open up the console and try to run the demo in preview view to see the error)

React Event System: SyntheticEvent

It turns out React has it's own event system for event handling, using SyntheticEvent.

React's SyntheticEvent wraps around the browser's native event to provide cross-browser compatibility support. Instead of passing in the native event to React event handlers, an instance of this SyntheticEvent is passed in.

The console warning I encountered occurs because React re-uses the SyntheticEvent object for performance reasons, by pooling the synthetic events all together. Thus, all the properties on event.target are nullified after an event callback is invoked.

Essentially, SyntheticEvent cannot be used asynchronously, because the event will no longer exist after the event callback has been invoked.

This is a problem, knowing that React's setState() behavior is asynchronous.

However, what if I want to use event.target within setState()?

  handleChange(e) {
    this.setState((prevState, props) => {
      return {
        username: e.target.value     // Attempting to use e.target.value
                                     // within setState()
      }
    })
  }

  render() {
    return (
        <input
          type="text"
          value={this.state.username}
          onChange={this.handleChange}
        />
    )
  }
}

Solution 1: Use React event.persist()

Using event.target to construct a new state is a common pattern, and React has provided a solution with event.persist().

Calling event.persist() on the event removes the synthetic event from the pool and allows references to the event to be retained asynchronously.

  handleChange(e) {
    e.persist();

    this.setState((prevState, props) => {
      return {
        username: e.target.value
      }
    })
  }

Solution 2: Cache event.target

Another solution is to cache the result of event.target within the event handler, and reference this cached value within the setState() callback.

  handleChange(e) {
    let inputValue = e.target.value;  // Cache the value of e.target.value

    this.setState((prevState, props) => {
      return {
        username: inputValue
      }
    })
  }

Let's take a look, specifically relating to patterns on binding the this context for class methods.

I. Quick Overview on Pure render()

The motivation behind keeping the render() method pure is to avoid issues when using shouldComponentUpdate(), and React.PureComponent, which work by performing shallow comparison checks.

The guidelines of a pure render() is:

• The contents of the render() method should not create new arrays, objects, or functions.
  • A new array, object, or function instance within render() will cause the shallow comparison to always fail. The Component will always re-render.
• That state is not mutated within setState().
  • A mutated state will not create a new state object, causing the shallow comparison to always succeed. The Component will not re-render.

Side Comment: Necessity of pure render() patterns?:

Pure render() patterns seem to only have benefits if you are utilizing the shouldComponentUpdate() method, or React.PureComponent.

Pure render() patterns are considered a "nice to have", but they are not mandatory in writing functioning (and for the most part, performant) React apps.

React will actually handle the performance of most, small, React apps perfectly fine.

Following a pure render() pattern may provide an easier transition, when shouldComponentUpdate() or React.PureComponent is actually needed.

In either case, it's good to understand what a pure/non-pure pattern implies in how the code functions. Let's dig in more...

II. this Binding in React render()

Most of the discussion, around maintaining pure render() methods, is regarding the this context binding within a render() method.

Assume the base case:

• Form Component with an ES6 class.
• State Object, with the property name, and value of Joe
• handleClick() method that console.log(this.state.name).
• render() method that just displays the button.

How should we attach handleClick() to the button, with a correctly bound this to the context of the Form Component instance?

class Form extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }
  }

  handleClick() {
    console.log(this.state.name); // Uncaught TypeError: Cannot read
                                  // property 'state' of null
  }

  render() {
    return (
      <button onClick={this.handleClick()}>  // How to bind 'this'
                                             // to Form Component instance?
        Click Me
      </button>
    );
  }
}

Problem: Binding this

The problem originates from ES6 classes not automatically binding the, this, context for methods on the class.

Without explicit this binding, when <button> Click Me </button> is clicked, the this context within the attached event handler, handleClick(), no longer points to the Form Component instance and we get the error:

Uncaught TypeError: Cannot read property 'state' of null  

Aside: When to pass props into super()?

I noticed there were code samples on various blog articles that differ in passing and omitting props into the super() method.

As a standard, the React team recommends:

"Class components should always call the base constructor with props".

For the curious minds: Apparently, passing props into super() allows access to this.props in the constructor().

Interestingly, if you omit passing props into super(), it does not affect access to this.props outside of the constructor() (ex. render(), componentDidMount(), etc. will still have access to this.props).

// Not recommended, omitting props.
constructor() {  
  super();

  ...
}


// Recommended: Always call the base constructor with props.
constructor(props) {  
  super(props);

  ...
}

III. Non-Pure render() Patterns - Binding this

Note: Most articles and tutorials I've seen commonly use these two non-pure patterns because of the succinct syntax. Using a non-pure pattern is absolutely fine for those situations. Again, most small React apps will perform perfectly fine using these non-pure render() patterns.

To reiterate, a pure render() should not create new functions within render().

The following two non-pure patterns, using .bind and arrow functions, return a new function every time the Component re-renders. This will cause problems when trying to utilize shouldComponentUpdate() and React.PurecComponent.

1. Calling bind() in render() - Non Pure render() Pattern

A common solution to resolve this binding context is to use bind(). This Javascript native method creates a new function that has its this keyword set to the provided context.

class Form extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }
  }

  handleClick() {
    console.log(this.state.name); // 'this' context in handleClick()
                                  // bound to Form Component instance
  }

  render() {
    return (
      <button onClick={this.handleClick.bind(this)}>  // Binding 'this'
        Click Me
      </button>
    );
  }
}

2. Arrow Functions - Non Pure render() Pattern

Another common solution to resolve this binding context, is to use arrow functions.

However, we are still returning a new instance of handleClick() from the arrow function every time the Component is re-rendered.

class Form  extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }
  }

  handleClick() {
    console.log(this.state.name); // 'this' context in handleClick()
                                  // bound to Form Component instance
  }

  render() {
    return (
      <button onClick={() => this.handleClick()}>  // Binding 'this'
        Click Me
      </button>
    );
  }
}

Note: Using arrow functions in render() is popular because it serves as a "useful" and convenient way to pass in arguments to an event handler. We'll touch on this more below.

class Form  extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }
  }

  handleClick(name) {
    console.log(name);
  }

  render() {
    return (

      // Binding 'this', and passing in an argument
      <button onClick={() => this.handleClick(this.state.name)}>
        Click Me
      </button>
    );
  }
}

IV. Pure render() Patterns - Binding this

The following pure render() patterns do not create new function instances within render(), allowing the shallow comparison check to work correctly.

1. Calling bind() in the Constructor - Pure render() Pattern

This solution still utilizes bind(), however, we assign the context bound function in the constructor of the Component.

class Form extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }

    this.handleClick = this.handleClick.bind(this);  // Binding 'this'
  }

  handleClick() {
    console.log(this.state.name); // 'this' context in handleClick()
                                  // bound to Form Component instance
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        Click Me
      </button>
    );
  }
}

2. Arrow Function Class Method- Pure render() Pattern

This solution takes advantage of a stage-2 experimental feature, Arrow Function Class Methods, allowing arrow functions to be used as class methods to preserve the this context of your method.

Note: Class properties are currently stage-2 and require an additional Babel plugin. I've included my .babelrc, webpack.config.js, and package.json at the end of the article for reference.

class Form extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }
  }

  // Arrow Function Method
  handleClick = () => {
    console.log(this.state.name); // 'this' context in handleClick()
                                  // bound to Form Component instance
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        Click Me
      </button>
    );
  }
}

3. Autobinding with React.createClass - Pure render() Pattern

ES6 Class syntax is the current standard for writing React (the React docs have also switched over to use ES6 Class syntax). However, when using the traditional syntax of React.createClass, the this context of methods in the Component are actually automatically bound.

var Form = React.createClass({  
  getInitialState () {
    return {
      name: 'Joe'  
    };
  },

  handleClick() {
    console.log(this.state.name); // 'this' context in handleClick()
                                  // bound to Form Component instance
  },

  render() {
    return (
      <button onClick={this.handleClick}/>
    );
  }
});

V. Passing Arguments to Methods in render()

This is an interesting problem - how do you keep the render() method pure, while passing arguments to event handlers?

1. Non Pure render(): Passing Arguments with Arrow Functions

There's nothing special here. An easy way to pass arguments to a method within render(), is to use arrow functions.

However, this is a non-pure pattern.

class Form  extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: 'Joe'
    }
  }

  handleClick(name) {
    console.log(name);
  }

  render() {
    return (

      // Binding 'this', and passing in an argument
      <button onClick={() => this.handleClick(this.state.name)}>
        Click Me
      </button>
    );
  }
}

2. Pure render(): Passing Arguments using Child Components

The concept of this pattern is to create a separate Component, <Button /> with its own event handler, wrapperHandler().

wrapperHandler() can call the parent's event handler, handleClick(), and pass in any arguments:

// Create a child Component

const Button = props => {  
  const wrapperHandler = () => {
    props.handleClick(props.name);  // Pass in arguments to the original
                                  // event handler 'props.handleClick'
  };

  return (
    <button onClick={wrapperHandler}>
      Click Me
    </button>
  );
};

With this pattern, we can ensure that the render() method remains pure, and we avoid creating new function instances on each render.

In the parent Component, we render an instance of the <Button /> Component we just created, and pass in the original event handler and any arguments, as props.

Note that the method, handleClick(), still needs to have its this context correctly bound. In this example, I chose to do the binding in the constructor().

class Form extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      name: "joe"
    };

    this.handleClick = this.handleClick.bind(this);  // Binding 'this'
  }

  handleClick(name) {
    console.log(name);
  };

  render() {
    return (
      <Button
        handleClick={this.handleClick}  // Pass 'this.handleClick'
                                        // as a prop called, 'handleClick'

        name={this.state.name} // Pass the argument
                               // as a prop called, 'name'
      />
    );
  }
}

The above example is pretty simple. Here's another example in React CodeSandbox that further illustrates this pattern.

Appendix: Using Babel Stage-2 Presets

// webpack.config.js

// Specify webpack to use the 'babel-loader' module, for .js file types.


var path = require('path');  
var HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {  
  entry: './app/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'index.bundle.js'
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader'
      },
      {
        exclude: /(node_modules)/,
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  },
  plugins: [new HtmlWebpackPlugin({
    template: 'app/index.html'
  })]
}

// .babelrc

// Include "stage-2", under "presets".


{
  "presets": ["env", "react", "stage-2"]
}

// package.json

// Add "babel-preset-stage-2" as a Dev Dependency.


"devDependencies": {
  "babel-core": "^6.25.0",
  "babel-loader": "^7.1.1",
  "babel-preset-env": "^1.6.0",
  "babel-preset-react": "^6.24.1",
  "babel-preset-stage-2": "^6.24.1",
  "css-loader": "^0.28.4",
  "html-webpack-plugin": "^2.29.0",
  "prop-types": "^15.5.10",
  "style-loader": "^0.18.2",
  "webpack": "^3.3.0",
  "webpack-dev-server": "^2.5.1"
},
"dependencies": {
  "react": "^15.6.1",
  "react-dom": "^15.6.1"
}

The below is just some documentation of my research for personal reference.

Mac OS: Package.json Webpack Build Script

The React docs provide the following script:

// package.json

  "scripts": {
    "build": "NODE_ENV='production' webpack -p"
  }

Windows: Package.json Webpack Build Script

However, trying to run the above script on a Windows machine (even using cygwin) will give you the error:

'NODE_ENV' is not recognized as an internal or external command, operable program or batch file.  

The script needs to be run slightly differently on Windows machines:

// package.json

  "scripts": {
    "build": "set NODE_ENV=production && webpack -p"
  }

Understanding The Scripts

1. package.json: Optimizing webpack for Production

The webpack production flag, webpack -p, is shorthand for --optimize-minimize --optimize-occurrence-order.

--optimize-minimize: Minimize scripts and CSS (if using css-loader).

--optimize-occurrence-order: webpack assigns IDs to modules and chunks (I believe for caching validation purposes). --optimize-occurrence-order makes sure that commonly used ids will have a smaller id length.

// package.json

// Set NODE_ENV for webpack to 'production'
// Use the Webpack 'production' shortcut, -p
  "scripts": {
    "build": "set NODE_ENV=production && webpack -p"
  }

2. webpack.config.js: Build React for Production and Minify JS

In webpack, DefinePlugin allows creating global constants that can be configured at compile time. This provides flexibility for different behaviors between development builds and release builds.

Tell React to use the production version of React

This instance of DefinePlugin performs a search-and-replace on the original source code, and instances of process.env.NODE_ENV in the imported code is replaced by "production".

React's internals has references to process.env.NODE_ENV. When set to, "production", React removes warning messages to reduce file-size and increase performance.

// webpack.config.js

    new webpack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production')
    })

Make webpack Minify Javascript code

webpack comes with UglifyJsPlugin, and uses UglifyJS to minimize the output.

// webpack.config.js

    new webpack.optimize.UglifyJsPlugin()

Complete webpack.config.js

// webpack.config.js

let path = require('path');  
let HtmlWebpackPlugin = require('html-webpack-plugin');  
let webpack = require('webpack');

let config = {  
  entry: './app/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'index.bundle.js',
    publicPath: '/'
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader'
      },
      {
        exclude: /(node_modules)/,
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  },
  devServer: {
    historyApiFallback: true
  },
  plugins: [new HtmlWebpackPlugin({
    template: 'app/index.html'
  })]
};

if (process.env.NODE_ENV === 'production') {  
  config.plugins.push(
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production')
    }),
    new webpack.optimize.UglifyJsPlugin()
  );
}

module.exports = config;  

Considering that managing component state is a fundamental aspect of React, I wanted to understand the common pitfalls and solutions around using setState().

First, a quick overview of setState() and its behavior.

setState() Signature:

setState(updater, [callback])  

setState() takes two arguments.

• An updater
  • Either an object literal OR a function.
• An optional callback
  • setState() is asynchronous.
  • The callback is called when the Component state has actually updated.

Passing updater an Object Literal

• Use the object literal pattern for simple state updates.
• Passing an object literal is succinct.

// Using an object literal in setState

this.setState({  
   selectedLang: 'Javascript'
});

Passing updater a Function

• Use the updater function pattern when updates need to reference the previous state.
• Passing an updater function provides access to prevState and current props.
• prevState is a reference to the previous state. It should not be directly mutated.

The Updater Function Signature:

(prevState, props) => stateChange

The updater function should build a new object based on the input from prevState and props

// Using an updater function in setState to build a new object

this.setState((prevState, props) => {  
  return {counter: prevState.counter + props.increment};
});

setState() Behavior:

When setState() is called it does two main things:

1 - Queues changes to the component state (it is asynchronous)

• Note: If an object literal is passed as an updater, React first merges the object you passed to setState() into the current state.

2 - Tells React that the component (and children) needs to be re-rendered with the updated state.

• React's reconciliation process

  • Create a new React Element tree (an object representation of the UI).
  • Diffs the new tree against the old tree.
  • Determines what changed, based on the updater passed to setState().
  • Updates the DOM.

• Note: Use React's lifecycle methods to run code at different stages in reconciliation

  • shouldComponentUpdate: Allows determining if the component should update itself by inspecting the previous and new state.
    • If return false, then componentWillUpdate and componentDidUpdate are not executed. The component UI won't re-render.
    • this.state will still be updated within the component.
  • componentWillUpdate: Run any code before the new state is set and rendering happens
  • render: Render the updates visually to the DOM
  • componentDidUpdate: Run any code after the new state is set and the component has re-rendered

Common Pitfalls with setState()

Pitfall 1: Trying to modify state directly

The first mistake with setState() is not using setState()! =)

• Do not modify state directly.
• Modifying this.state directly will not trigger a Component re-render.
• The only place where this.state should be assigned is in the component's constructor.

// WRONG: This will not re-render the component

this.state.discount = false;  

Solution: Use setState()

setState() will trigger a re-render of the Component.

// CORRECT: Use setState()

this.setState({  
  discount: false
})

Aside: When should something be stored in Component state?

• If you don't use something in render(), it shouldn't be in this.state.

Pitfall 2: Trying to use setState synchronously

setState() is asynchronous. Do not call setState on one line and assume the state has already changed on the next line.

• setState() is a request to update state, rather than an immediate command to update state.
• setState() does not always immediately update the component.

// WRONG: setState() should not be used synchronously

// assuming this.state = { orders: 0 }
this.setState({  
  orders: 1
});

console.log(this.state.orders); // BUG! Prints out: 0  

There are two solutions to this mistake:

• Use the componentDidUpdate() lifecycle method (recommended by the React team).
• Pass a callback as a second argument to setState().

Using componentDidUpdate or a setState callback (setState(updater, callback)) guarantees your code will execute after the state update has been applied.

Solution 1: Use the componentDidUpdate() lifecycle method

componentDidUpdate() is invoked immediately after updating occurs (but is not called on the initial render of the Component).

// CORRECT: Use the componentDidUpdate() lifecycle method

componentDidUpdate(prevProps, prevState) {  
  console.log(this.state.orders); // Prints out: 1
}

Solution 2: Pass a callback function to setState()

The second parameter to setState() is an optional callback function that will be executed once setState is completed and the component is re-rendered.

// CORRECT: Pass a callback as a second argument to setState()

// assuming this.state = { orders: 0 }
this.setState({  
  orders: 1
}, () => {
  console.log(this.state.orders); // Prints out: 1
});

Pitfall 3: Trying to use a previous value of state

setState() is asynchronous. Consequently, the vales of this.state should not be used for calculating the next state.

• this.props and this.state may be updated asynchronously.
• this.state should not be used to calculate the next state.

// WRONG: Don't rely on this.state to calculate the next state

this.setState({  
  orders: this.state.orders + this.props.increment,
});

Solution: Use the updater function form to access prevState

The first argument of the updater function, prevState, provides access to the previous state:

Updater function signature:

(prevState, props) => stateChange

// CORRECT: Use the updater function form to access prevState

this.setState((prevState, props) => ({  
  orders: prevState.orders + props.increment
}));

Pitfall 4: Trying to issue multiple setState() calls

Multiple setState() calls during the same cycle may be batched. This is specifically an issue when passing updater an object literal.

• setState() performs a shallow merge of the updater object into the new state.
• Subsequent setState() calls will override values from previous calls in the same cycle.
• If the updater objects have the same keys, the value of the key, of the last object passed to Object.assign(), overrides the previous value.

// WRONG: Using an object literal with multiple setState calls during the same cycle will shallow merge the objects

// assuming this.state = { orders: 0 };
this.setState({ orders: this.state.orders + 1});  
this.setState({ orders: this.state.orders + 1});  
this.setState({ orders: this.state.orders + 1});

// --> OUTPUT: this.state.orders will be 1, not 3 as we would expect


// It is equivalent of an Object.assign, which performs a shallow merge
// The orders will only be incremented once

Object.assign(  
  previousState,
  {orders: state.orders + 1},
  {orders: state.orders + 1},
  {orders: state.orders + 1},
  ...
)

Solution: Use the updater function form to queue state updates

By passing updater a function, the updates will be queued and later executed in the order they were called.

//CORRECT: Use the updater function form to queue state updates

// assuming this.state = { orders : 0 };
this.setState((prevState) => ({ orders: prevState.orders + 1}));  
this.setState((prevState) => ({ orders: prevState.orders + 1}));  
this.setState((prevState) => ({ orders: prevState.orders + 1}));

// --> OUTPUT: this.state.orders will be 3

• React provides a declarative library that keeps the DOM in sync with your data.
• React components just render props and state.
• React components just represent the UI at a certain point in time.
• Use the componentDidMount method to fetch data with AJAX.

TLDR; Skip to the codesandbox snippet below to take a look at the code

Random Aside: The cool thing is that grokking this 'React Thinking' has helped to structure my code at work. Our stack at iHerb is just jQuery *cries*, and so it's super easy to start writing a spaghetti mess. Our team made some significant strides by refactoring to follow the module and prototype pattern, but having this 'React Thinking', making the UI a representation of application state, has drastically increased the maintainability of our code.

React Components Just Render props and state

React just renders components, and data in React comes from two places: props or state.

When thinking about where to fetch data in React, the underlying concept is that data needs to somehow get into the component's props or state.

React Components Represent the UI at a Certain Point in Time

The beauty of React is that a component is just supposed to represent the UI at a certain point in time.

The render() method, therefore, should not have any code that contain side effects, nor anything that is asynchronous in nature. It is just suppose take the current props and state and represent that as DOM elements.

Fetch Data in the componentDidMount lifecycle method

The componentDidMount method is the recommended place to make any AJAX data calls.

The componentDidMount method only executes once during a component’s life: at the point when the component mounts to the DOM for the first time.

By using this lifecycle method, it is clear that data won’t be loaded until after the initial render and enforces the pattern of setting up an initial default state to prevent any undefined state that could result in unexpected app behaviour.

Below is a simple example of how we can update a component’s state (a list of GitHub repos) with this.setState in the componentDidMount method. Once the state is updated, React triggers a re-render, and then the repos are rendered to the DOM.

export default class GitHubRepos extends React.Component {  
  constructor(props) {
    super(props);

    this.state = {
      repos: []
    };
  }
  componentDidMount() {
    axios
      .get(
        window.encodeURI(
          `https://api.github.com/search/repositories
             q=stars:>1+language:javascript&sort=stars&order=desc&type=Repositories`,
        ),
      )
      .then(response => {
        const repos = response.data.items;
        this.setState({
          repos
        });
      })
      .catch(error => {
        console.log(error);
      });
  }

The full code is in my codesandbox below:

Caveat with Fetching Data in componentWillMount

It seems logical to use the componentWillMount method to load data, since the goal is to have data loaded into the app before it gets rendered to the DOM.

However, fetching data with AJAX happens asynchronously. There is no way to pause or delay React from continuing to render the component (maybe with a hacky setTimeout? I haven't tried..).

The component will end up rendering before that data is loaded.

The problem with using componentWillMount is it isn't explicit (to the developer / maintainer) that the component will render without data at least once. By assuming that the component will have data returned on first-render, the developer could naively skip setting up the component's default state, and the handling of default state.

Without setting default a state, the initial render of the component will have a state of undefined (and probably some bugs to track down!).

I pulled this table out from the video for comparing between cookies, localStorage, and sessionStorage.

Comparing Cookies, localStorage, and sessionStorage

Security Considerations

(Source: https://stackoverflow.com/questions/19867599/what-is-the-difference-between-localstorage-sessionstorage-session-and-cookies)

• Cookies, sessionStorage and localStorage should only be used for persisting non-sensitive data between pages since they can be read and modified from the client
• Cookies information can be intercepted in transit if not on HTTPS
• Cookies should use the HTTPonly flag will prevent access to the cookies and values from JavaScript
• Cookies should not be used to store large amounts of information since all cookies valid for a page are sent for every request to the same domain.

I quickly realized, though, that improving my Dev Tools proficiency meant first solidifying my understanding on the browser; specifically, the Critical Rendering Path.

You have to know what you're looking for, in order to analyze it, right? =)

TLDR; Optimizing the Critical Rendering Path involves optimizing the dependencies between HTML, CSS, and JavaScript and reducing the time required to process and turn them into rendered pixels.

Critical Rendering Path

Let's take a high level look at the Critical Rendering Path. (If you want to dig deep into the full path, check out Google's Web Fundamentals.)

The Critical Rendering Path can be separated into two main portions: network transmission, and browser processing.

Network Transmission: Involves the key steps to receive the HTML, CSS, and JavaScript assets.

Render Processing: Involves the processing steps to turn these assets into rendered pixels (first paint).

In order to render a page, the web browser needs to receive the HTML and CSS, and respectively build the Document Object Model (DOM) and the CSS Object Model (CSSOM). Thus, both HTML and CSS are render blocking resources.

In addition to render blocking HTML and CSS, by default (without the async attribute), JavaScript execution is also a render blocking resource as the execution of any included scripts will block the browser parser until the script's execution is completed.

Breaking Down the Critical Rendering Path

When you request a webpage (aka. type in a URL), the website's server sends back the page's HTML. HTML documents not only contain the content of the site, but also references to any external CSS and JavaScript resources.

Building the DOM and CCSOM

After the HTML is received, the browser begins parsing the received bytes to create the Document Object Model DOM.

Bytes → Characters → Tokens → Nodes → Document Object Model

While parsing the HTML, if the browser comes across an external resource reference, the browser will send off a network request to fetch the file. For example, when the browser comes across a link tag <link href="style.css" rel="stylesheet">, it will send off a network request to retrieve the CSS stylesheet .

When the CSS file is received, the same parsing process happens on the CSS file to create the CSS Object Model.

Bytes → Characters → Tokens → Nodes → CSS Object Model

JavaScript Blocks DOM Creation and Page Rendering

JavaScript resources also have the potential to block and delay the render of the page as the execution of any scripts will block the browser parser.

Image: Parser blocking script files

When the browser comes across an inline <script> tag, the browser will pause/block the parser and DOM creation process for the entire time it takes to both fetch the script across the network, and for the JavaScript engine to execute the script.

This parser blocking behaviour is detrimental to user-experience, since a network roundtrip could add thousands of milliseconds of delay to the critical rendering path!

Furthermore, another important behaviour to be aware of is that script execution will only begin after all prior referenced CSS resources have been downloaded and their CCSOM has been constructed.

Basically, script execution is itself blocked until the CCSOM has been constructed.

As you can see, there are many ways that Javascript resources can block the Critical Rendering Path and time to first render.

Optimizing the Critical Rendering Path

Essentially, optimizing the Critical Rendering Path involves minimizing the total amount of time spent performing each step in the render path:

1. Processing HTML markup and building the DOM tree
2. Processing CSS markup and building the CSSOM tree
3. Combining the DOM and CSSOM into a render tree
4. Executing JavaScript files

Optimizing the CSSOM and the complexity of style calculations has it's own focus. I'll just be looking at optimizing script loading in this article.

Optimizing Script Loading

Okay, that was a lot of background info - let's dig into my take-aways on optimizing script loading.

Baseline - Regular Script Loading:

<script src="first.js"></script>  
<script src="//domain.com/second.js"></script>  

In this situation, the browser will block the parser while it downloads both scripts in parallel. The scripts will then be executed in order of declaration in the HTML.

• second.js won’t execute until first.js has executed.
• first.js won’t execute until the CSSOM has been fully parsed, and until any previous scripts are executed.
• The Critical Rending Path is blocked while all this is happening.

Comments: This is the least optimal method of loading scripts.

Even if we try to prevent blocking the DOM by placing the <script> at the end of the document, right before the </body> tag, the browser won't fetch the script until the whole document has been parsed.

Ideally, we would like to begin fetching these scripts asynchronously, as soon as possible, and then execute them when they're received across the network.

Asynchronously Load Scripts with async

Image: async script files

<script src="first.js" async></script>  
<script src="//domain.com/second.js" async></script>  

In this situation, the the async attribute tells the browser that the script is not part of the critical rendering path. The browser downloads both scripts in parallel, but the parser continues to construct the DOM while the resources are being fetched.

As soon as a script file is received across the network, it will be executed in the order it is received. This can introduce dependency issues as the order of declaration is not maintained!

• The browser parser is not blocked while scripts are fetched.
• Scripts will execute as soon as it is retrieved, regardless of the order it was defined in the document.
• Scripts do not wait for the CSSOM to be fully parsed.

Comments: Using the async attribute is the best practice as it allows script references to be placed in the <head>, so that they can be fetched early on and asynchronously.

However, even async scripts still block the browser parser during script execution. So a long-running script could still potentially delay the first paint.

Defer Script Loading with defer

In this situation, the the defer attribute not only tells the browser to prevent the parser from being blocked while the scripts are being fetched, but to also delay script execution until after the document has been parsed (just before domContentLoaded is fired).

All deferred scripts will also maintain their declaration order.

<script src="first.js" defer></script>  
<script src="//domain.com/second.js" defer></script>  

Comments: The best uses for defer are for any non-critical scripts, like analytics, ad networks, social networks, etc. that don't provide any core functionality to your website / app.

In addition to administrative announcements, we each take turns to give a mini presentation, which we've unoriginally called Front End Developer Talks, aka FED Talks (hopefully TED Talks doesn't chase us on trademark infringement...).

It's both a way to share knowledge, and a medium for us to practice talking to developers.

Generally the topic is anything fun/cool/random that we've been working on, or a new technology that we've been experimenting with.

This past week was my turn and I shared two things:
1. My journey into jQuery's source code
2. A fun little exercise on Javscript's this assignment I had been playing around in a Codepen.

I'll take you through an exercise on Javascript's this assignment.

Example 1: this points to window, in a globally invoked function

//Global variable, greeting.
var greeting = 'hello';

//Global function, sayGreeting.
function sayGreeting(){  
    console.log('greeting:', this.greeting);
}

sayGreeting(); //Result: hello  

In this example the variable, greeting, and the function, sayGreeting, are both in the global context.

sayGreeting() is called in the global context, so the keyword this in sayGreeting points to window when it is invoked.

Example 2: this points to the object, in an invoked method

//Constructor French which stores a property, greeting
var French = function (greeting){  
    this.greeting = greeting;
}

//French.prototype which has a method sayGreeting
French.prototype = {  
  sayGreeting: function() {
    console.log('greeting:', this.greeting);
  }
}

//Create a new object, louis
var louis = new French('bonjour');

louis.sayGreeting() //Result: bonjour  

In this example the variable, louis.greeting, and the method, louis.sayGreeting, are both properties of the object louis.

louis.sayGreeting() is called in the context of the object louis, the keyword this in louis.sayGreeting points to the object louis, when it is invoked.

Question: What does this point to, when a method is assigned to a global variable and invoked?

//borrowedGreeting points to the method, louis.sayGreeting
var borrowedGreeting = louis.sayGreeting;

borrowedGreeting(); //Result: ??  

So now we have an interesting case!

borrowedGreeting is a global variable, which points to the method, louis.sayGreeting, on the object louis.

Essentially, borrowedGreeting will console.log(this.greeting). However, which this does it point to?

There is a global variable, greeting.
But there is also a property, louis.greeting.

borrowedGreeting(); //Result: hello  

Take Away: this points to the object which invoked the function

Interesting! Even though borrowedGreeting points to the method louis.sayGreeting, the object which invoked the function is window.

We can look at it another way:

window.borrowedGreeting()  

A quick shortcut to figuring out the this assignment in a function, is to look to the left of the function call to see which object is invoking it.

Further Reading: Assign the this context of function calls

If we wanted to get borrowedGreeting to log out bonjour, we can use Function.prototype.call() to assign the this context of the function.

borrowedGreeting.call(louis); //Result: bonjour  

For a full explanation, I'll point you to this great article by one of my Javascript heros, Yehuda Katz: Understanding Javascript Function Invocation and "this"

Hope you had fun following through this little exercise!

The obvious starting point was jQuery, since it's at the core of all our DOM manipulation code we write.

Here's a quick link: https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.js

*I didn't get too far into the source since it's a pretty long library, but I did have two interesting take-aways.

1. What is jQuery.fn?

One of the first questions I had in mind was regarding jQuery.fn. I previously knew that writing a jQuery plugin involves defining a new method on the jQuery.fn object, but why, and what is, jQuery.fn?

Near the top of jQuery's source lies the answer (well, part of the answer).

jQuery.fn = jQuery.prototype { ... }  

That makes sense. If we want to create a new plugin that we can use from the jQuery object, we need to add it to jQuery's prototype object.

That's a standard Javascript pattern called the Prototype Pattern.

Still, that seems like a strange pattern of creating a pointer to the jQuery.prototype called jQuery.fn. After a bit of Googling, I came across this Google Groups discussion, jQuery Prototype Magic.

$.prototype wasn't used for anything; instead, every time a jQuery object was created, all of the method references found in $.fn were copied, one by one, into the new jQuery object.

As you can guess, this was a bit slow, and I came up with a patch to use $.prototype in the conventional manner instead of copying all the methods. $.fn was kept as an alias of $.prototype for compatibility with existing plugins that already used $.fn.

**So the main take away is, jQuery.fn points to jQuery.prototype, and jQuery.fn is still used for backwards compatibility sake.

2. $(...) doesn't 'technically' return a jQuery object

// Define a local copy of jQuery
var jQuery = function( selector, context ) {

        // The jQuery object is actually just the
        // init constructor 'enhanced'
        return new jQuery.fn.init( selector, context );
};

var init = jQuery.fn.init = function(...) {...};

init.prototype = jQuery.fn;  

We're all taught that when we use the $(...) selector, jQuery returns a new jQuery object with a collection of elements for you to act on.

Interestingly though, jQuery's source reveals that the constructor is actually jQuery.fn.init. So 'technically', we're actually getting back a new jQuery.fn.init object.

That leads to another interesting line of code:

init.prototype = jQuery.fn;  

The reason for this line of code explained by the 4 things that happen when we use the new operator in Javascript

1. A new object is created, inheriting from the constructor's prototype
2. The constructor function is called with any specified arguments
3. this is bound to the newly created object
4. The newly created object is returned

So, new jQuery.fn.init( selector, context ) returns a new jQuery.fn.init object. However, the prototype of jQuery.fn.init is empty.

Since we want our new jQuery object to have access to all the useful jQuery methods that we know and love like .find() and .addClass(), the prototype of init needs to point to jQuery's prototype in access jQuery's other methods.

You can think of

init.prototype = jQuery.fn;  

to be re-written as

jQuery.prototype.init.prototype = jQuery.prototype  

Whew, that was a mouthful, but hopefully that sheds some light on what jQuery is actually doing when you're using it!

Open Preferences: User Settings

"emmet.syntaxProfiles": {
    "javascript": "jsx"
}

A simple fix, but man I'm so happy to have Emmet working again!

Understanding the different use cases for each allows for clear data management and a clean pattern when thinking about React component composition by creating Controller Views and 'dumb' Presentation Components.

Props and State

Data for React components are stored as props and state

React props

var UserForm = React.createClass({  
    getDefaultProps: function() {
        return {
            name: 'fullname',
            placeholder: 'Enter your name',
            value: ''
        };
    },
    render: function() {
        return (
            <CustomInput type="text"
               name={this.props.name}
               className="form-control"
               placeholder={this.props.placeholder}
               value={this.props.value}
               onChange={this.props.onChange}
            />
        );
    }
});

• props (aka. properties) are references to parameters that are passed down from parent components.
• The data is owned by the parent so prop data is immutable within the child component.
• props facilitates uni-directional data-flow from parent to child components.

getDefaultProps

• If the parent component doesn't declare value, you can set default props with getDefaultProps.

prop Validation

props can be validated through React.PropTypes, though it only runs in development environment of React. (By default, minified version of React runs in production mode.)

React.PropTypes allows setting explicit expectations about the expected data type for a component's props. It's a good way to debug, but since it only runs in dev environment, it's shouldn't be used in production to validate props.

Note: props that aren't required should have a default prop defined with getDefaultProps

Use React.PropTypes to Specify type: number, string, bool, etc.

React.PropTypes.array  
React.PropTypes.bool  
React.PropTypes.func  
React.PropTypes.number  
React.PropTypes.object  
React.PropTypes.string  

propTypes: Maps a validation function for each prop

propTypes: {  
    author: React.PropTypes.object.isRequired,
    onSave: React.PropTypes.func.isRequired,
    validate: React.PropTypes.func.isRequired,
    errors: React.PropTypes.object,
    hasErrors: React.PropTypes.func.isRequired
}

React state

var ManageAuthors = React.createClass({  
    getInitialState: function() {
        return {
            author: { id: '', firstName: '', lastName: '' }
        };
    },
    render: function() {
        return (
           <AuthorForm
            author={this.state.author}
            //onChange, run this.setAuthorState function
            onChange={this.setAuthorState}
            onSave={this.saveAuthor}
           />
        );
    }
});

• state should be used in controller views (the top level component). This allows separating logic from Presentation Component markup.
• state data is owned by the component so state is mutable data.
• state is passed down to nested child components as immutable data via props.

getInitialState

• Typically only used to set default state in the top level (controller view) component.

Component Composition - Controller Views

A Controller View is a convention to have a single, top level view that:

• Owns state data
• Interacts with any stores
• Passes data down to children via props.

Setting up and thinking about Controller View component composition allows for cleaner data management:

• Provides a single, logical place to interact with Flux/Redux stores.
• Always know where data is coming from and where the source of truth is.
• Data flow is controlled for all child component by setting props on children components.

I'll follow up with another post on component creation techniques to talk more about Controller Views and Presentation Components.

Mounting

componentWillMount

When does it hook:

• Before initial render, both client and server (DOM does not exist yet).

What situations to use it:

• Provides a way to set the component's initial state.

componentDidMount

When does it hook:

• After the DOM has rendered.
• Both the DOM and component have rendered when this function is called.

What situations to use it

• When access to the DOM is needed.
• A good place to set timers, AJAX requests.

Updating

These lifecyle methods will occur when parents change properties and then setState.

componentWillReceiveProps

When does it hook:

• Runs just before new props are received.
• Note: componentWillReceiveProps is not called on initial render.

What situations to use it:

• Use it when props have changed and to setState before the component re-renders.

shouldComponentUpdate

When does it hook:

• Runs before render and when new props or state are being received.
• Note: shouldComponentUpdate is not called on initial render.

What situations to use it:

• Use it to tweak the app's performance.
• Sometimes props and state changes, but the component doesn't need to rerender (when it doesn't affect the DOM).
• Return false to void unnecessary re-renders.

componentWillUpdate

When does it hook:

• Immediately before rendering the component, after props or state have been received.
• Note: componentWillUpdate is not called on initial render.

What situations to use it:

• Prepare for a render update.
• Note: setState can't be called in this function.

componentDidUpdate

When does it hook:

• After component updates are rendered to the DOM.
• Note: componentDidUpdate is not called on initial render.

What situations to use it:

• Now that the component has been rendered, operations on the DOM can be done here.
• Any DOM manipulations after an update.

Unmounting

componentWillUnmount

When does it hook:

• Immediately before the component is removed from the DOM.

What situations to use it:

• Cleanup of any event listeners etc.

Although my code is now organized and modular, it still feels tangled and tightly coupled to many other portions of the codebase.

After a bit more reading I came across the Publish/Subscribe (Observer) pattern and this seems to be the answer to my problem.

Here's another JavaScript patterns brain dump.

So far I've been using Morgan Roderick's PubSubJS library to implement Pub/Sub communication in my code: https://github.com/mroderick/PubSubJS

Decoupling Code

Code is tightly coupled when objects directly call the methods of other objects. Instead, the pub/sub pattern allows a dependent object to 'subscribe' to a specific event of another object and is notified when the event occurs.

One of the main goals of the pub/sub pattern is to avoid dependencies between the subscriber and the publisher.

Pub/Sub allows code to be decoupled and broken down into smaller, loosely coupled modules. When an event is published, a notify message is sent out. All the subscribed observers receive the message and can invoke their callbacks.

Essentially, publishers notify subscribers when events occur.

Subscribers can listen to these notifications and execute code in response to the event.

Encouraging Reusable Modules

With loosely coupled code, each component of the system is only concerned with it's own responsibility and doesn’t care directly about the logic of any other components.

This allows for easy reuse of different modules since modules are not directly coupled with the interfaces of other modules.

I've always been intrigued by the chaining pattern that jQuery implements. It's such an elegant way to present an API: it's both concise, and readable.

//Example
$('.foo')
    .addClass('bar')
    .html('hello world')
    .fadeIn('slow');

It turns out that the fundamentals of this pattern isn't that complicated.

(I'll update you guys again when I actually try to implement it into my code... hah)

The main key to the chaining pattern involves returning the object at the end of each method using return this, which allows additional methods to be called on the object again.

I've written a short codepen to play around with this chaining pattern.

See the Pen JavaScript Chaining Pattern by Duncan (@duncanleung) on CodePen.

For clarity sake, this is the textbook Prototype Pattern

// Constructor function to create Person objects
function Person(name, age, gender) {  
    this.name = name;
    this.age = age;
    this.gender = gender;
}

// Constructor prototype to share properties and methods
Person.prototype.sayName = function() {  
    console.log('My name is ', this.name);    
};

Person.prototype.sayAge = function() {  
    console.log('My age is ', this.age);
}

In our codebase, I was seeing a nice 'short-hand(?)' to declare methods on the prototype by assigning an object literal with the methods to Person.prototype.

// Constructor function to create Person objects
function Person(name, age, gender) {  
    this.name = name;
    this.age = age;
    this.gender = gender;
}

// Constructor prototype to share properties and methods
Person.prototype = {  
    this.sayName: function() {
        console.log('My name is ', this.name);    
    },

    this.sayAge = function() {
        console.log('My age is ', this.age);
    }
}

But something didn't sit right and I remembered reading about issues using this object literal short-hand.

Caveat: You're Overwriting the Prototype Object!

Say we've created a new jim object, from the Person constructor function.

var jim = new Person('Jim', 12, 'Male');  

The caveat with using the short-hand variation of the prototype pattern occurs when you try to call the jim.constructor property. You would expect jim.constructor to point to the Person constructor function. Instead, it points to the function Object {...} constructor function. What?

The fix is to explicitly declare the constructor property on Person.prototype when using the object literal assignment to the function's prototype.

Person.prototype = {  
    constructor: Person,

    .... //other methods
}

Prototype Chain: What's Happening In the Background

When you define a function, a prototype object (example: Person.prototype for the constructor function) is automatically created with a default property Person.prototype.constructor which points to the constructor function.

All new objects created from Person can access and reference the Person constructor function via the prototype chain, which delegates to Person.prototype.constructor.

1: Person constructor function is created.

var Person = function () {...}  

2: Person.prototype object is automatically created with a default property, constructor.

Person.prototype = {  
    constructor: Person
}

3: A new object jim is instantiated from Person. The object jim is automatically linked to Person.prototype via the prototype chain.

Note: jim.hasOwnProperty('constructor') //false

var jim = new Person('Jim', 12, 'Male');  

4: Calling jim.constructor actually calls Person.prototype.constructor via the prototype chain.

Person.prototype = {  
    constructor: Person
}

5: However, if Person.prototype is overwritten, Person.prototype.hasOwnProperty('constructor') is now false! The call then delegates further up the prototype chain to the base Object constructor function.

This is why we were seeing jim.constructor pointing to the function Object {...} constructor function.

So, using an object literal to define the methods on Person.prototype, actually overwrites the object.

To allow instantiated objects to reference the constructor function, the property Person.prototype.constructor needs to be manually declared.