React’s lifecycle methods give us specific points at which to tap into the ‘lifecycle’ of a component (and it’s children) and provide an organized structure in which to interact with components as they are mounted, rendered, updated, and unmounted as state changes.

This post is intended to be a quick guide into the component lifecycle methods for easy reference. They are listed in the order which they are invoked.

componentWillMount( )

Invoked once on client and server before the initial rendering occurs (before component.render is called). Load initial data here with an AJAX call.

component.render( )

Every component requires a render method. This is a 'pure' method, meaning that it will return the same result every time it is invoked.

The render method exclusively examines this.props and this.state and must return a single child element, null, or false if nothing should be rendered. If it is being called in a parent component, the children can be placed within a it’s opening and closing tags, e.g. {this.props.children}.

It doesn’t read from or write to the DOM, interact with the browser, or modify component state.

componentDidMount( )

Invoked only on the client after rendering has completed. This method has access to a component’s children (and their DOM representation) and you can can use setTimeout, events, or AJAX calls here.

componentWillReceiveProps( nextProps )

Invoked when a component is receiving new props. This is an opportunity to react to prop transitions. This method may or may not cause a state change using this.setState( { prop: value } ).

shouldComponentUpdate( {newProps}, {newState} )

If new props/state is being received by a component, this method is invoked before render happens. Returns true by default, return false to skip render. If it returns true, the rest of the lifecycle methods below will be invoked.

componentWillUpdate( {nextProps}, {nextState} )

Invoked immediately before render as an opportunity to prepare for update. You cannot use this.setState() here. Use componentWillReceiveProps instead.

componentDidUpdate( {prevProps}, {prevState} )

Invoked after component’s state changes and updates are applied to the DOM. It is acceptable to operate on the DOM here.

componentWillUnmount( )

Before a component is unmounted, this method is called. Any necessary cleanup goes here (e.g. invalidating timers, changing DOM elements, etc.).

And that’s it! It seems like a lot for simple changes in state, but each of these methods correspond to a specific point during the lifecycle of a component and allow maximum control over the rendering of that component. It will probably not be necessary to customize and utilize each one of these methods for each component, but the option is there.

Happy Reacting!

Backbone is no longer the hot new thing on the block, but many new and experienced developers alike are still grappling with creating a satisfying mental model for the framework that would (ideally) help us better understand what’s going on, at least from a high-level perspective. The fact that backbone doesn’t follow the typical MVC or even MVVM pattern makes it difficult to place into any logical category.

I wish to propose a solution to this problem by suggesting a simple comparison (allegory, maybe?) to abstract away the details of code and understand Backbone from a mile-high perspective.

Imagine we have a set of Backbone views on a page. As we likely already know, each view is tied to a specific DOM element, though not all DOM elements are represented by views. Assume that each of these views are a way for us to render information that exists on its model by appending it to the DOM. A collection is simply a group of these objects that are built from a single model. Collections can also have a view.

We'll ignore the innards of the views for now (template, render, tagName, etc.). For now, that’s all we need in order to draw a vivid comparison.

Think about a model. It is created with the Backbone.Model.extend({...}) method and probably contains a defaults property that holds some information about it. Now replace that model with an infant human child. No unique or identifying features, just the characteristics common to all babies. Basically the idea of a baby.

The model is just the template for a baby, not any baby in particular. When we actually... ahem... instantiate a baby, it will have unique properties to it (age, DOB, name, etc.) as well as some abilities (cry, eat, whatever else babies do). This translates to a Backbone View that contains all of the methods available to all babies, as well as some HTML, that we can liken to a diaper. A collection of babies is just that. Still with me? Good.

Some event that happens on a view we can liken to a baby soiling it’s diaper. What happens next?

When any baby notices it’s diaper has been soiled, it cries. This is similar to an event being ‘triggered’ on its model. This event is also triggered on the collection. When you have a group of babies, you know when one is crying. Mom, for our purposes, can be thought of as the overarching app model. The app model knows to expect these events, and knows how to deal with them, whether it will be making a change to the view, adding something to a collection, or deleting it entirely. Mom is the same (except she probably isn’t deleting babies). She hears a crying child, changes it’s diaper, and waits for the next event (being a mother does sound glamorous).

So, the comparison goes:
Human infant = model

Individual baby (with name, age, diaper) = view

Mom = app model

Backbone can listen for ‘change’ events on each model and perform an action for you every time that change occurs, then re-render those elements for you. Mom is a good listener and knows how to change dirty diapers into fresh ones. She also knows how to act when a baby is hungry or tired, she just needs the baby to cry to tell her it’s time to change it. Just like our app model needs some sort of event or interaction on the view to tell it how to react.

Granted, this comparison isn’t perfect, but I hope it helps you visualize the control flow of a Backbone application next time you’re drawing a blank.

Shoutout to Melinda Bernardo for inspiration for this post.