Why we choose ReactJS at HelloClass
It’s been few months since we deployed our web app for tutors, where they can take sessions and answer student’s queries. It was a simple web app written with jquery, css and HTML, which creates an MQTT connection with back-end and enables chat between student and tutor. It was fast, working fine but as the features on the app was growing, it has become difficult to manage DOM manipulations. On an average, the app was adding a new element to DOM in every 5 secs or so. We had used old school JS template solution where the new element comes from one of the template and is appended at the respective place. But only problem was, we were reinventing the wheel, that too a flat one. We had to manage event binding and unbinding manually, manipulating DOM based the data which is getting changed over time. Like in our case getting a new chat message and adding it to the respective chat window. All of these we had to manage explicitly. Then our search for a stable UI framework begun. When we were researching, we were looking for framework where we can re-use our UI code as much as possible and make code more manageable.
Stumbling upon few framework landed us on ReactJS. It had everything we were looking for, a virtual DOM where addition and deletion of elements was easier. Each DOM element can react to user actions. And to fuel our seeker mind, it has ECMA script 7 support too. We created an POC with React with bare minimum features. Just a chat interface which creates MQTT connection to our Message Broker and interacts with our Go back-end APIs. We were able to roll out this over a weekend and gave it for test to few selected users. Results were positive. It was faster, less connection drops (in old interface, we had iframes for each chat window, thus had inconsistent behavior) and best of all, we had accomplished the same features in lesser LOC.
Once we had surety that ReactJS is right fit for our application. We started writing for production. We separated each attachable/detachable UI component as React suggests. One thing that took a while to digest was to write HTML code in JS files. There were no separate HTML resource other than the shell page. But once we had written enough code, writing JSx wasn’t too bad. In fact if you look at it in terms of maintainability of the code, you’ll find it more convenient once you are at it. For example, say there is a chat-window component (hence call it chat-window.js) If any issue comes (be it a html or JS fix) You know where to look at into the code-base. This becomes extremely helpful when your web app starts to grow.
ReactJS composable components use props and state to hold the component’s data. This is again a place where we had a confusion on when to use props and when to use state. There is no boolean answer for this question, but as we started using it we realized that state is something which is private to a component and hence shouldn’t be modified by other components. Anything else which you think will change or should be updated by other components, should be carried in props. ReactJS community suggests the same. The best part about using props and state is that you just update this data and React takes care of updating the component (and the actual DOM) by itself.
We used custom events to pass data between components, wherever the parent-child relationship, between components was not there. Custom events wasn’t a concern since we were not developing for IE since day one.
We implemented React in a multi page app setup, although we have 90% of our functionality on a single page, rest of the pages serve more of static content. Since, react compiles its components to bundles, and we were in multi page setup, we had to create multiple bundles and load them on respective page. A react bundle has all required js files plus components with HTML into a single file, which turn outs to be quite large file. This was causing problem when user is on slow network. We leveraged application cache for this. All bundles were cached at browser so, first load was slow but subsequent network calls were only API calls. All content were served from local. This worked for us since users for this app were tutors, and they spend an average of 4 hours on this platform, taking session, helping students.
To conclude, react is a good choice for applications where there is high DOM manipulation and have UI components that themselves has elaborate functionality. Learning curve for react is very shallow, only new concept is of writing JS and HTML together, once that is understood, writing react is piece of cake.