React Component Lifecycle

As it stands currently, I have just recently graduated from the Flatiron School, and now days are no longer spent on labs and lecture, but more on jobs. In fact, through the Flatiron School, I was fortunate enough to meet with a few companies with the hopes of eventually landing a job. In my first interview, I was asked to describe the component lifecycle of a simple to-do application. I was able to summarize what I thought were the necessary steps involved correctly (I think…).

Afterwards, I thought to myself if my answer, not necessarily correct, hit all the right points. So I scoured the interwebs to try and reinforce what I knew and to also add more insight. In short, my answer to question consisted of the following steps with the following facts:


The to-do application is comprised of an input field, with a button that allows the user to add to-do’s to their list of to-do’s. Below this field, all of the current user’s to-do’s are rendered. A back-end API is set up for any requests needed for the application.

Based off this information, I formed my answer with the following steps:

  1. Lifecycle begins once user clicks on the “add todo” button.
  2. This will make a request to the API to create and store a new to-do.
  3. Once request has been resolved, dispatch an action, presumably, “ADD_TODO”.
  4. Update state of the store within the reducer.
  5. Update DOM based on any changes to the state.

Once the interview ended, I kept thinking to myself if my response hit all the marks. Of course, there were a few things I knew I could’ve mentioned, but totally forgot, such as…

  1. Assuming the interviewer knew about the necessity of having thunk. Without this middleware, an issue would arise with asynchronous actions in React. If I attempt to make an API request, there’s a possibility that subsequent lines of code will process before the request resolves. With thunk, your action now returns a dispatch function, allowing you to dispatch actions after your request has completely resolved.
  2. I made the assumption and never asked whether the application requires authentication. As part of making API requests, it is good to know whether the user is authorized to make those requests. I would’ve mentioned that as part of making a request, I will need to authenticate the user through a JWT token to ensure an authorized user is the one making changes to the application.
  3. Another aspect I would have liked to do is frame my response around the phases of a component’s lifecycle — initialization, mounting, updating, and unmounting as it pertains to the to-do application.

Overall, I felt pretty proud of my response, but of course, there’s no such thing as perfect. So although I didn’t completely botch the question, it gave me an opportunity to do more research on a topic that is a staple feature of React.