Are the lifecycle methods a design pattern of its own, or is it a more general class of design pattern?

Question

Today I saw that React (React JS) has lifecycle methods, such as

componentWillMount()

and so when the component or container is instantiated for the first time, this method will be called if it exists. (if it is defined).

One example of it is, when the component is instantiated for the first time, if the above method componentWillMount() is defined in the class, then it will be called, and it may do an AJAX call to fetch data to populate into this component.

And the same is true for iOS or Cocoa programming:

viewDidLoad()
viewWillAppear()

and this type of "if it exists (or is defined), then call it" actually was similar to the old days of

document.getElementById("foo").onclick = function() { };

That is, if onclick is defined, then call it. Otherwise, just ignore it. But this is related more to event handling / observer pattern / chain of responsibility, more than lifecycle methods.

(Having said, actually, you can also view lifecycle methods as event handlers too: such as, now the View or Component will be shown, I (the OS or the framework) am telling you / notifying you (about this event): if you need to do something, do it now (handle it now)).

The question is: do these lifecycle methods componentWillMount(), viewWillApear() a design pattern of its own, or do they belong to a bigger class or more general class of design pattern?

Answer 1

As you said in native Javascript you have already plenty of events handler :

• onShow
• onClick
• onFocus
• ...

These are just the same principle wrapped in the framework, and they added some their own.

For me it's not a specific pattern, it's just how Javascript (and even UI) usually works : event based.

Answer 2

One could argue that this is an instance of pipe-and-filter architectural pattern. Usually it is used to process data through multiple steps and the output of each step is an input to another.

Although, this does not fit the provided description, since no explicit data is passed between the steps (in this case the functions), there is clearly a correlation between the functions - one does not start before the previous is finished. Additionally, the manual changes from each function/process can be seen as implicit data filtering, and the current (updated) context can be considered as the passed data to the next process/function.

It is a quite common naturally occurring pattern, so you can find it in many places. Considering this, I don't think it as important as understanding the different processes that happen in the chain and in which cases they are executed/skipped.