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


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:


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?

  • They're just boolean functions. They're used all the time when you want to retrieve some sort of status. It doesn't seem to me that using them in this particular context affords them any special status. Apr 5, 2017 at 17:43
  • no, AFAIK, they DO something. Such as, in componentWillMount(), the programmer can do AJAX call to fetch data particular to that component Apr 5, 2017 at 17:45
  • You mean they have side effects? Boo. Apr 5, 2017 at 17:45
  • @RobertHarvey actually, these aren't boolran, they're event handler functions.
    – Jules
    Apr 5, 2017 at 17:46
  • 1
    Yeah, I was right; they're boolean functions. See here. Though it says that "You can override this method to perform additional tasks associated with presenting the view," can I be the first to say "yuck?" Apr 5, 2017 at 17:48

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.