Lifecycle Methods in React, and The Wheel of Karma

In React, one of the more basic concepts for class based components is that of Lifecycle Methods. When thinking in only technical context the concept seems easy enough, but the ideas blur when it comes to implementing them. With that in mind, this analogy of Karma and The Wheel of Life may help.

Imagine a Human class that extends React.Component. Suppose for the sake of this analogy that “React.Component” is how a component (in this case, a human) taps into the mysteries of the universe.

The constructor methods’ super(props) might be likened to a human becoming at one with the universe.

So, in this context, consider the constructor methods as “Gestation towards Birth, and Actual Birth.” The properties of a human that are created during the constructor phase might be inherited from the parents, such as eye color, hair color, and other physical properties.

After the constructor phase comes rendering. If you’ve ever heard any existential musings like “The way that I look in the mirror is always the same for me, but perhaps you might see a completely different person” or “is my version of the color green the same as your version of the color green?”… the unifying idea behind both these wonderings is that of “shared reality” despite differences in presentation for the participants.

To think of “rendering” in another sense, consider how different comic book artists “render” the likeness of Bruce Wayne (Batman), or the Joker. And yet, all the “constructor elements” remain the same; Joker is never rendered as Scarecrow, and Scarecrow is never “rendered” as Batman etc…

Or, to put it in technical terms: what “renders” on your desktop browser may be the “same likeness”, but not the “same kind”, as when it is rendered on an iOS or Android mobile.

To sum up constructors and renderings: Consider the “constructors” to be the physical properties of one being born into this world. Consider rendering as a matter of appearance.

Once The Human has been constructed and rendered we have componentDidMount. Within componentDidMount we handle state/setState where aspects of the Human are determined. For example, the states of “relationship karma”, or “financial karma” or “fortune” or “honor” are set; things that have a starting value but may change over time. In other words, a human’s physical state is determined at birth, barring surgery, or injury. As for “destiny”? That may be set with initial “karmic” values (based on one’s past life, or even contemporary “family karma”). However, the destiny of a component/human is subject to change. While the starting state of componentDidMount renders once and for all (as a human might be born with “karma”), it is not unalterable, so long as action is taken to update one’s karma.

To put it another way, componentDidMount can be likened to the proclamation of an oracle reading your destiny at birth, but also advising that all is not set in stone… that one’s destiny can change based on what values are taken as input.

And that brings us to componentDidUpdate.

Over the course of Component Human’s Life, there will be many happenings of componentDidUpdate… any time some action is taken (from inputs, onClicks, onSubmits, onChanges). Any time action is taken, the state of the human is altered; action taken could be likened to setState on one’s karma.

To further extend the analogy, all the cells in your body are replaced every 7 years. One might consider you to be a completely different person, today, as opposed to who you were 7 years ago. Perhaps we can say it takes “7 years” for componentDidUpdate to take place in the real world, and re-render you anew. It’s also worth mentioning that render actually takes place every time state is altered. So, if one was a ne’er-do-well, perhaps the way they rendered during their evil times afforded them a sinister countenance; but, if they worked hard to change their ‘karmic state’ and were thus “re-rendered”; the sinister countenance of 7 years ago might be replaced with one more endearing… so much so that you might consider this ‘same body’ as a completely different person.

State (and properties) in the context of componentDidUpdate allow you to change the fundamental nature of a component, although that component (as it was constructed) remains the same; no matter how many times we “componentDidUpdate” in life, our component self remains the same, though our state DOES change.

Lastly, we have componentWillUnmount. While this final idea might seem a bit abstract as a strictly technical Component Lifecycle… it may be thought of more simply as: “when the state (or property) of one’s life force is set to null, then the ‘component’ will die… and reenter the wheel of life.”

There are other Lifecycle Methods. But hopefully this analogy will allow you to think more memorably about the basics.