Advanced ReactJS Interview Questions

1. How does React decide to re-render a component?

In react, a re-render can only be triggered if a component’s state has changed. The state can change from a props change, or from a direct setState change. The component gets the updated state and react decides if it should re-render the component. Unfortunately, by default React re-renders everything all the time.

Component changed? Re-render. 

Parent changed? Re-render. 

Section of props that doesn’t actually impact the view changed? Re-render. 

Well, but re-rendering all the time isn’t helpful. 

Yes, re-rendering unnecessarily does waste cycles and is generally not a good idea. However, React can’t “just know” when it’s safe to ignore parts of the state. So it plays it safe and re-renders whenever there’s a change to the state, important or not.

How to Avoid re-rendering?

By default, shouldComponentUpdate returns true. That’s what causes the “update everything all the time” we saw above. However, you can overwrite shouldComponentUpdate to give it more “smarts” if you need the performance boost. Instead of letting React re-render all the time, you can tell React when you don’t want to trigger a re-render.

2. Explain how events are handled in React.

The event handlers in React will be passed instances of SyntheticEvent to solve cross-browser compatibility issues. SyntheticEvent is React’s cross-browser wrapper around the browser’s native event. The synthetic events have the same interface as the native ones but they work identically across all browsers.

However, React doesn’t actually attach events to the child nodes themselves. Instead, it uses a single event listener in order to listen to all events at the top level which. Not only is this great for the performance but it also means that React doesn’t have to keep track of the event listeners when updating the DOM.

3. Is setState() async? Why?

setState() actions are indeed asynchronous. setState() doesn’t immediately mutate this.state. Instead, it creates a pending state transition. Accessing this.state after calling this method can potentially return the existing value. There is no guarantee of synchronous operation of calls to setState and calls may be batched for performance gains.

The reason behind is the way setState alters the state and causes rerendering. Making it synchronous might leave the browser unresponsive. That being said, the setState calls are asynchronous as well as batched for better UI experience and performance. Keep this in mind as this is definitely among the most popular 50 interview questions and answers when it comes to React.

4. Explain the components of Redux.

This is another common Redux React question. You should know that Redux is composed of the following components:

  • Action — The action is the only source of information that sends data from our application to our store. Actions are sent the store using store.dispatch().
  • Reducer — Reducers specify how the app’s state changes in response to actions sent to the store. Since the actions don’t show the application’s state changes, this place determines how the state will change to an action.
  • Store — The Store is the object that brings Action and Reducer together. The store has the following responsibilities: Holds application state; Allows access to the state via getState(); Allows state to be updated via dispatch(action); Registers listeners via subscribe(listener); Handles unregistering of listeners via the function returned by subscribe (listener).

That being said, keep in mind that there is only a single store in a Redux application. When we want to split the data handling logic, we need to use the reducer composition instead of many stores.

5. What is Redux Thunk used for?


A thunk is another word for a function. But it’s not just any old function. It’s a special (and uncommon) name for a function that’s returned by another. Like this:

function wrapper_function() {  // this one is a "thunk" because it defers work for later:  return function thunk() {   // it can be named, or anonymous    console.log('do stuff now');  };}

You already know this pattern. You just don’t call it “thunk.” If you want to execute the “do stuff now” part, you have to call it like wrapper_function()() – calling it twice, basically.


If you want an action to do something, that code needs to live inside a function. That function (the “thunk”) is a bundle of work to be done.

It would be nice if an action creator could return that function — the bundle of work — instead of an action object. Something like this:

function getUser() { 
 return function() {  
  return axios.get('/current_user'); 

If only there were some way to teach Redux how to deal with functions as actions.

Well, this is exactly what redux-thunk does: it is a middleware that looks at every action that passes through the system, and if it’s a function, it calls that function. That’s all it does.

Leave a Reply

Your email address will not be published. Required fields are marked *