This course is archived!

While the concepts of this course are still largely applicable, it's built using an older version of Symfony (4) and React (16).

Login to bookmark this video
Buy Access to Course
34.

Temporary Messages & componentWillUnmount

Share this awesome video!

|

Keep on Learning!

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

That success message is cool... but it should probably disappear after a few seconds. No problem! We can use the native setTimeout() function to change the state back to empty after a few seconds.

Go back to RepLogApp. Let's refactor things first: create a new method called setSuccessMessage with a message argument. Inside, set the state.

112 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 83
setSuccessMessage(message) {
this.setState({
successMessage: message
});
// ... lines 88 - 93
}
// ... lines 95 - 112

We're making this change so that we can re-use our cool success message feature in the future. Above, instead of setting the successMessage in the object, use this.setSuccessMessage() and paste the text there.

112 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 39
handleAddRepLog(item, reps) {
// ... lines 41 - 49
createRepLog(newRep)
.then(repLog => {
// ... lines 52 - 60
this.setSuccessMessage('Rep Log Saved!');
})
;
}
// ... lines 65 - 112

Watch out for Multiple Re-Renders

But! There is a downside to what we just did! Every time you change the state, React re-renders our component. Thanks to this change, it's going to re-render once for this state and then again right after. That is probably not something you need to worry about. But, as your applications grow bigger and bigger and bigger, you should be aware when you're triggering your app to re-render. This is especially important because, when a component like RepLogApp re-renders, all of its children are also re-rendered, even if the props being passed to them don't change. And yes, there are ways to optimize this. But, for now, just be aware that re-rendering requires CPU. If you re-render a big app too often, it could slow down. But, there are ways to optimize.

Clearing the Message with setTimeout()

Back in setSuccessMessage(), to clear the message, use setTimeout(), pass it an arrow function, and use this.setState() to reset successMessage back to empty quotes. Let's do that after 3 seconds.

112 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 84
this.setState({
// ... lines 86 - 88
setTimeout(() => {
this.setState({
successMessage: ''
});
}, 3000)
}
// ... lines 95 - 112

Ok! Let's give this a try! Refresh and lift my big fat cat 5 times. Success! And... gone!

Clearing the Timeout

So easy! Except... yes... it was too easy. There's an edge case: if setSuccessMessage() is called once, then called again 2 seconds later, the second message will disappear after only 1 second! It's a minor detail, but we can code this better.

Basically, before we call setTimeout, we want to make sure to clear any previous timeout that may be waiting to fire. The setTimeout() function returns an integer, which we can use to clear it. To keep track of that value, in the constructor, initialize a new property: this.successMessageTimeoutHandle = 0.

119 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 7
constructor(props) {
// ... lines 9 - 18
this.successMessageTimeoutHandle = 0;
// ... lines 20 - 24
}
// ... lines 26 - 119

This has nothing to do with React: we're just taking advantage of our object to store some data. Oh, and the value 0 is just a "null" value in disguise: if we pass this to clearTimeout(), nothing will happen.

Back down in setSuccessMessage, before setTimeout, add clearTimeout(this.successMessageTimeoutHandle). To set that property, add this.successMessageTimeoutHandle = before setTimeout().

119 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 88
setSuccessMessage(message) {
// ... lines 90 - 93
clearTimeout(this.successMessageTimeoutHandle);
this.successMessageTimeoutHandle = setTimeout(() => {
// ... lines 96 - 100
}
// ... lines 102 - 119

And finally, to be completely on top of things, inside the callback, after we reset the state, set the timeout handle back to 0.

119 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 94
this.successMessageTimeoutHandle = setTimeout(() => {
// ... lines 96 - 98
this.successMessageTimeoutHandle = 0;
}, 3000)
// ... lines 101 - 119

Cleaning up Your Component: componentWillUnmount()

And... we're done! Our message will always disappear a full 3 seconds after the last success message has been set. Except... yea... there is still one teenie, tiny problem... and this time, it's special to React.

Right now, RepLogApp will always be rendered on the page. But, that's not true of React components in general. For example, we could choose to only render the RepLogCreator component after clicking a button. Or, if you're using React Router so that users can navigate to different "pages", then even RepLogApp would be rendered and unrendered as the user navigates.

Because of this, if your component is removed from the page, you need to ask yourself:

Is there anything I need to clean up?

The answer is usually... no! But, setTimeout() would cause a problem. Why? Basically, if setState() is called on a component that is not rendered to the page, React kinda freaks out. Thanks to setTimeout(), that could happen if the component was removed right after setting a success message.

It's not a big deal, but let's clean this up. Scroll up to componentDidMount() and add a new method: componentWillUnmount().

119 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 36
componentWillUnmount() {
// ... line 38
}
// ... lines 40 - 119

This is another one of those magic lifecycle functions: componentDidMount is called right after your component is rendered to the page. componentWillUnmount is called right before it's removed. It's your chance to clean stuff up.

Let's do that: clearTimeout(this.successMessageTimeoutHandle).

119 lines | assets/js/RepLog/RepLogApp.js
// ... lines 1 - 36
componentWillUnmount() {
clearTimeout(this.successMessageTimeoutHandle);
}
// ... lines 40 - 119

Honestly, this isn't that common. But, keep it in mind. Another example could be if you used an external library to add some cool feature directly to a DOM element. If you want to clean that up, this is the place to do it.