Thinking in React

I have been working in React, Flux and Redux for last few years and have gone through numerous success and failure experiences in it. This experience have given me a fare bit of knowledge on React and I thought of sharing it with you.

The major one which strikes me most is about “ thinking in react”, majority of new react developers have failed to adopt react as such because of the lack of “thinking in react way”.

avaScript and JavaScript class libraries and frameworks undergoes massive evolution for the past few years. React stood in front among that journey which allows us to develop rich client based highly performing single page applications.

Understand it correctly

The main part of learning react starts with understand the key things correctly. Props/State, life cycle events and the way of constructing a react component correctly. It is always good to have a basic understanding on what is happening behind the scene before start using the same. Try to get a basic knowledge of Reconciliation, Diff algorithm and the component tree then it is easy to understand that how the component get re-rendered , when we need to use or change props and state.

Understanding the life cycle events is really important because writing wrong thing in wrong event may end up in hell. Get a clear understanding on each life cycle like when it will get triggered and what action should we do in that. For example if you are writing some code to change the state unconditionally in componentDidUpdate() it will end up in an infinite re-rendering. Another example is attaching an event listener in didUpdate(), which will end up with n number of reference and the memory usage will rise.

Do you really need a state management mechanism by default?

No, is the answer. You don’t need one unless it is really painful for you to manage the state using private state. Nowadays there is trend like going for redux or any state management by default with every react project. Believe me , you can build cool apps with private state with less complexity and maintainability. The new Context API offers you great way to pass data from parent to grand child and which will help you to avoid unwanted props in intermediate components. I suggest you to think twice before you choosing a state management mechanism. Worth reading a good article from Dan Abramov on this here.

Understand your component structure

Ultimately you are going to create some html which will be rendering in the browser, keep this in mind while you are creating the components. A component does this for you in react, while render it will returns the html.Our aim here is to reuse the components as much as possible so design your component as tiny as possible. Once you got the html take a look and decide which all components need a state and which are not. Don’t go for a state until you really need that, avoid the hassles of state management by creating it as a stateless component.

Understand the new release Roadmap

React has their release Road map where they describes the journey towards asynchronous rendering and concurrent rendering. Keep this in mind because all the new releases coming with changes align with this road map. So we need to careful while developing our app and that should use the pattern or architecture which align with this road map so that it will be easy to upgrade to newer version and use those interesting features quickly.

Best practices in React and Flux


React is a wonderful class library which can be used to develop rich client application by ensuring better performance. Flux is the architecture which gives the beauty of uni-directional data flow and immutability of data. React+Flux is always a good choice while you starting your web application.I would like to share some thoughts on the good practices we can follow while developing an app using react and flux.

No direct store update

The unidirectional data flow gives the beauty of single source of truth, however it is a choice. Flux doing nothing to prevent you making it bidirectional, you can always update the store from your component directly with out initiating an action creator and action. If you want to follow flux don’t do this.

Call setState appropriately

One another mistake is calling setstate inside render. You can call setState anywhere other than render. However try to avoid unconditional setstate inside componentDidupdate() as it may lead to infinite re-rendering since didUpdate calls whenever a component has re-rendered.

Avoid updating the DOM directly and use ref wisely

Since react is doing the job of DOM update using virtual DOM it is a bad practice to update the DOM directly using conventional methods.Instead use ref to read the DOM and update the DOM react way by calling setState and re-rendering.

Always use unique key to the components

React internally identifies the components using key so it is important to make sure that you are using unique names for the react components.

vDo not add listeners in willReceiveProps or didUpdate().

Do not add event listeners in componentDidUpdate() and componentWillReceiveProps()

Adding event listeners in didUpdate and willReceiveprops is a bad idea as both life cycle events (willReceiveprops is deprecated from the latest version 16.4 onward) will trigger more than once based on props change or state change. So adding listeners in those event cause multiple reference of the event listeners and cause memory leak.

Stateless as much as possible and Tiny Components

It is always good to go for the stateless and tiny components whenever possible. This can improve the performance by avoiding the life cycle.

Bind the callback functions inside the constructor

Avoid binding the context while passing a call back function as prop to child component. If you are passing like that it will be creating a new reference every time and cause re-render of your pure child component. Instead bind the context in constructor and pass the same as prop.

class Parent extends React.Component{
    // Bind the context here
    this.callBackFunc = this.callBackFunc.bind(this)
    return ( <Child callBack={this.callBackFunc});