Lifecycle Events (Components)

Growing up with a relatively religious family and having worked for a non-profit centered around intergenerational education, I’ve spent a lot of time thinking about how we mark lifecycle events.

As I see it, there are 3 categories of rituals demarcating these milestones:

  1. those that happen in preparation for an event — such as the specifications in many cultures for how brides prepare for a wedding, (ie Moroccan henna celebrations, immersing in water three times)
  2. those that are part of the lifecycle event itself — the ceremony that composes a wedding (ie vows, exchanging of rings, breaking a glass), or that dictate what a funeral looks like
  3. those that are designated to come after a lifecycle event takes place — such as baby-naming ceremonies or mourning practices, which often happen after a predetermined amount of time has passed

In our code, the functions that compose the Component Lifecycle take on a similar structure

  1. The four components that happen in preparation:
  • shouldComponentUpdate
  • componentWillUpdate
  • componentWillReceiveProps
  • componentWillMount

2. the event itself — render

3. The threepost-event lifecycle components:

  • componentDidMount
  • componentDidUpdate
  • componentWillUnMount

Memorizing and understanding these has been a challenge for me. I’m going to try go in order (or at lease the order that makes the most sense to me) to explain them and their uses.

Before Render

  1. shouldComponentUpdate — this checks if the event, render, needs to happen at all (ie, is the engagement still on?) and returns true or false
  2. componentWillUpdate — this ONLY gets called if shouldComponentUpdate returns true. (continuing the analogy, engagement is still on! continue wedding prep.) It cannot call setState, it can apparently do other things to prepare for the render. It seems pretty useless, except that some people use it instead of componentWillReceiveProps, event though it’s less powerful because it can’t change state.
  3. componentWillReceiveProps — this function does change the state based on the props. It is pretty much independent of the render, except that it is useful to change the state here before the render happens. It is also called many times, so it checks if the props will change and only updates the state some of the times it is called.
  4. componentWillMount — not exactly clear why you would use this. Seems that it happens less frequently than the others. You CAN put fetch or AJAX calls in here, but it’s not the best place for them.

After Render

  1. componentDidMount — this one actually seems useful. It is where changes to the DOM or new data fetches/Ajax calls happen, ie “side effects” are created. All the things you couldn’t do without having the DOM set up. Can also use this to set intervals that happen automatically.
  2. componentDidUpdate — Updates the page based on the prop changes.(Sometimes the settings in willReceiveProps are sufficient though).
  3. componentWillUnmount — all aforementioned “side effects” are cleared and dismantled, such as removing event listeners, canceling fetch requests, or clearing a “setInterval” that we might have started earlier in the code.

With some help from the internet and the react docs, I made a VERY basic timer function. It relies on componentWillMount to start automatically on the render of the page, and componentWillUnMount to eventually clear the timer.

Here the class is created and the interval is set to start counting seconds, and our componentWillUnMount is ready to clear it upon the “stop” button

class App extends React.Component {
constructor (props) {
super(props)
this.state = {count: 1}
}
componentDidMount =() => {
this.timer = setInterval(this.countUp.bind(this), 1000)
}
componentWillUnmount () {
clearInterval(this.timer)
}

here’s the rest of the code that makes it actually work — the method to count up from zero, and the render

countUp () {
this.setState({count: (this.state.count + 1)})
}

render () {
return (
<div className='timer'>
<h1>this timer started {this.state.count} seconds ago</h1>
</div>
</div>
)
}
}

It is super basic, but shows how things can work automatically based on the render rather than on user input. If you wanted to have a start button and not start automatically, instead of using componentWillMount, you would have a start timer button that looks exactly like our componentWillMount, but instead of being triggered by the page render it would be dependent on the user’s input:

 startTimer () {
this.timer = setInterval(this.countUp.bind(this), 1000)
}

Take Aways:

  1. It seems that componentDidMount, at least in this instance, serves a pretty similar function to using componentWillReceiveProps.
  2. Some uses, as pointed out by others of why you would want to use these: starting animation in css or canvas, having a countdown clock to let the user know how long an item will stay in their cart before someone else can purchase it (ie buying tickets for a show, auctions on ebay — somehow these still exist), or inputting a confirmation code after it is sent.
  3. The biggest thing that I have learned is that willMount / willUnmount generally seem to operate independently of the user, while shouldUpdate and willReceiveProps are more likely to be set off by user input changes.
  4. Lots of apps can function without these lifecycle methods.

helpful links: