Welcome Sencha developer! So, you want to learn React. Maybe you’re wondering where to start? Well, getting a basic understanding of React’s components is a great place to start. A big plus is that, like ExtJS, React’s components have some simple lifecycle events. Lucky for us, we can use our knowledge of ExtJS lifecycle events to help us understand React’s and that gives us a nice place to start learning. So, let’s take a quick look at them and see if we can understand when to use each one.
constructor (not an event but important)
“Life can only be understood backwards; but it must be lived forwards.” – S. Kierkegaard
Yes, I know. This is not an event but it’s well worth mentioning. For those of you who are used to beginning your ExtJS components with initComponent(), then constructor() will be where you get started. OK, ‘nuff said. Let’s look at these events.
componentWillMount
“Any fool can know. The point is to understand.” – A. Einstein
You can think of this event much like beforeRender. It’s called only once on both the client and server (depending on where you are executing). As you’d expect, this happens just before the initial render. If you set the component state here you will still only get the initial render and not an extra one. Usually changing a component’s state will cause it to re-render. However, changing it here is one of the exceptions.
componentDidMount
“What the mind doesn’t understand, it worships or fears.” – A. Walker
This method is similar to afterRender and is called only once on the client (not the server). Child component componentDidMount methods are called before the parent. This is where you can get initial access to the DOM and is the best place to hook in other frameworks and set up any other DOM interactions. It’s also the best place to make AJAX requests and set timers. You will definitely use this one quite a bit.
componentWillReceiveProps
“We have to make mistakes, it’s how we learn compassion for others.” – C. Sittenfeld
This one doesn’t really have a direct comparator in ExtJS. However, if it helps, you can think of this as something of a “setter”. It will get called after the initial render whenever our component’s props are received.
shouldComponentUpdate
“Nobody is smarter than you are. And what if they are? What good is their understanding doing you?” – T. McKenna
Here is another event without a direct comparator. It is called before rendering, but not for the initial render, whenever props or state changes. Much like an “apply” method in ExtJS, it’s preventable. So, you can return false to skip an update if you think it would be unnecessary. nextProps and nextState are the incoming arguments. You can easily compare them to the current props and state to determine if the next render event can be skipped. A good use case to use if it is an entire section of the UI tree can safely be omitted from virtual dom diff calc.
** Caution ** Unless you have a really good reason, this method should always return true or simply not be used. Otherwise, things might get buggy and/or out of sync.
componentWillUpdate
“Never memorize something that you can look up.” – A. Einstein
If shouldComponentUpdate does not return false, then this event will be called right after. You can use this opportunity to prepare for the upcoming update if you need to. Unlike shouldComponentUpdate, this event is not preventable.
componentDidUpdate
“Don’t cry and don’t rage. Understand.” – B. Spinoza
This is another method that you can think of as a bit like afterRender. However, the big difference is that componentDidUpdate will be called right after the render method for every update except for the initial render. This is similar to componentDidMount except that componentDidMount is only called once, after the initial render.
componentWillUnmount
“I write to understand as much as to be understood.” – E. Wiesel
You can compare this directly to onDestroy and it should be used exactly the same way. Clean up any extra objects you created, timers you set in componentDidMount etc. As you’d expect, this method is called just before our component is removed from the DOM.
Summary
I hope you found this quick ExtJS <-> React event comparison helpful. As always, don’t let your quest for knowledge end here. Head on over to React Documentation to broaden your understanding some more. If you have any comments or wisdom to share with me in return, leave them below or look me up on Twitter!
Featured image: ©www.tOrange.us This work is licensed under a Creative Commons Attribution 4.0 International License
