How React Shaped Haptik’s Frontend Story

Shaped Haptiks Frontend Story

In case if you have not noticed, Haptik now offers enterprise solutions to build and maintain AI chatbots for different industries (check out our Coca-Cola Bot). It is enthralling to be able to build bots for different people/verticals and fulfill their use cases. But as they say, with great power comes great responsibilities.


At Haptik, we have built various tools to cater to the needs of our customer. As an enterprise customer you are most likely to have a need to instantly change a reply of your bot; add more features to it or look how the bot is performing in a day to day life.


Haptik’s enterprise solution offers everything. From a simple drag-n-drop Bot Builder tool to a live chat monitoring application; from a Javascript Bot-integration SDK for your website to an analytics dashboard which explains everything about your bot – we have them all. And you guessed it right – everything is built with/using React.




In general, these tools are of very complex nature and have a learning edge associated with them. For example, in the following paragraphs, describes is one of our offerings to our enterprise customers and we call it Teja (Yeah, we do. Why? Cause, Andaz Apna Apna rocks. Period).


This tool is a dashboard that shows all the relevant information regarding the performance of a bot. There are different ways and semantics in which way one can analyze the performance of a bot and this tool try to deliver a medium to those aspects/areas.





The above screenshot is from Teja (a live chat monitoring dashboard) depicting some of the key metrics for the Trains Channel at Haptik in the staging environment. As you might have noticed, there are a lot of actionable areas and a lot of data to be processed and displayed. For example, clicking on a tree node from the Data Table will change the pie chart information displayed on the left. Similarly, clicking on any area of the pie chart will update the data table accordingly which includes a few API calls which are very well managed by React’s lifecycle processes.


At first glance, this looks quite simple; listening to some events and managing actions. Next, is just taking care of event bubblings and propagations and you should be good to go. We thought so too.


But things get messy when the number of events or user actions increases which can change the state of the application. You tend to mess up remembering who does what and who changes what. No, it’s not your memory which is at fault, it’s the sheer unstructured nature of Javascript and jQuery alike. That is why you need a framework/system to help you through.


Luckily for us, what came handy was React. React is a declarative, efficient, and flexible JavaScript library for building user interfaces. In simple terms, React is something which allows one to build a component which is (mostly) state driven. This state can be of the application or of some other components’. This implies that any action happening in the application has to change some sort of state of the application. If the state does not change, you can assume no actions have been performed. You can read more about it.







Though there are many state/data-driven libraries out there, so what’s so special about React? Here’s a list of few; which might be there in some other libraries as well but we love how React enforces/defines these rules or features:


  1. 1. The Virtual DOM. Yeah obviously.
  3. 2. React Encourages Components. This makes one create different components to be used in multiple parts of the application. In few cases, one can even re-use Project A’s component in Project B.
  5. 3. React Enforces One-way Data Flow. Unlike AngularJS (1.x) or jQuery, React only allows one to change the state of the application either from the View (the UI) or a methodology one concretely defines. This means that there are only a handful number of ways in which one can change the data/state of a component — and this helps in clean and bug-free code development. Let’s see the below code:
class MyInputBox extends React.Component {
constructor(props) {
   this.state = { value: '' };
   this.handleChange = this.handleChange.bind(this);

handleChange(e) {
   this.setState({ value: });

render() {
   return (
     <input value={this.state.value} onChange={this.handleChange} />


Here, the only way the value of the input field can change is when the user is typing something in the input box. Any other part of the application or any event in the system cannot change the value of the input field as the component strictly defines the data flow. This feature of React particularly removes lots of bugs and indeed is one of our favorite features.


  1. 4. React Allows Explicit App State. The props basically. React allows developers to control what changes the state and one can also define who changes the state. Let’s consider the below example:
class MyInputBox extends React.Component {
render() {
  return (
     <input value={this.props.value} onChange={this.props.handleChange} />


Here, the component is not managing its own state but allowing the parent component to do so via Props. This allows extensibility and gives the parent full control of the child component’s state. A very useful feature indeed.


  1. 5. The Stateless Components. A stateless component in React does not follow the lifecycle methods of React. This sometimes is a benefit where one piece of code does not necessarily need the React lifecycle stretches. This results in superior syntax, testability, and readability. However, it is to be remembered that every time a stateless component is called, entire VDOM will be rendered even if nothing has changed.

A stateless component in React is nothing but a pure function which can be written as below:

  1. class MyInputBox = (value, handleChange) => {
    return (
       <input value={value} onChange={handleChange} />


  2. 6. The Community Support. React has a very widespread community support. While I was writing this blog, the GitHub repository of React had more than 81K stars along with 1.2K contributors. There are a lot of high-quality open source libraries to chose from and it turns out that for anything and everything there’s already code available. This is very helpful for startups like us who want to ship code in a fast & easy manner.

But how do all these add up in real life? Let’s take the above product and assume it was built in jQuery/Javascript without the use of any framework/library. It is most likely that at one point in time we could encounter the following:


  • 1. Written a lot of code
  • 2. Out of which most cannot be reused
  • 3. Very little can be tested
  • 4. And unable to find the root cause of bugs as we are not sure what might have triggered a particular scenario.

All of the above can be solved with React. In React, we are encouraged to write components which can be reused at multiple places. We can create a one-way data flow to make sure we always know what can change our component. We can test each component and be pretty confident that we are shipping bug-free code.




React by default is not our first choice for any project (For eg. for one recent size constraint product we used Google’s Incremental DOM). At Haptik, we always believe in trying out the latest technologies out there and see how those can help us improve/develop our product.

Before choosing any frontend (or backend) technology stack we try to consider the following:


  1. 1. How the framework helps us build the most important features of the product?
  2. 2. Is the framework state/component based?
  3. 3. Is the team familiar with the framework? If not, how much do they need to learn?
  4. 4. The choices of open source libraries for the framework. (For e.g. Material design CSS library written in your choice of framework)
  5. 5. Community support and the core contributors.
  6. 6. Is the framework production ready?
  7. 7. How easy is it to test the framework? (Yes, we do believe in unit/integration tests)
  8. 8. How will any future major pivot/enhancements be?
  9. 9. What will be the size impact of the framework on the final product?

Upon validating we found out that most of the times React was the ultimate winner for us. For one of our latest offerings, we compared React with VueJS, Inferno, Angular 2, Ember and found that React suits us the best (although VueJS came pretty close). And with the supporting high-quality add-ons such as Flux/Redux, React-Router, Jest, Relay + GraphQL – we are ready to go tackle any kind of front end problems out there.


We are quite happy with the way React is helping us build cutting-edge products. And with the introduction of React Fiber and it being MIT licensed – we could not be any happier.


We are currently trying out React Fiber (16.0) in the production environment and we will soon be sharing our journey. In the meantime, if you find Haptik’s journey with React interesting and would like to join the awesome React team (or have any feedback/suggestions), do not hesitate to REACT and mail us on

Related Articles

View All