The content for this blog post comes from our develepment team, mainly from Marcin, Satu and Sten who do most of the work related to front-end development.

Last year we wrote a blog post about how and why we selected the front-end framework for our dashboard. We picked React because its component-based architecture gave us a lot of benefits. Chiefly, we felt that React might be the easiest to introduce gradually into an existing app. Another nice thing about React is the vast community, which is actively developing and updating the libraries.

The initial idea was to convert our app to React one user interface component at a time. This way the rewrite could be broken down into smaller pieces in a natural way. Basically, reducing the risk related to a software rewrite and still gaining benefits during the transition.

As planned, we started adding React gradually component by component. React enabled us to divide a page into smaller components and reuse those components on other pages, for example, our service level metrics and server metrics pages use the same search component. At the moment we have converted all pages in our dashboard into React, except the user, register, and login pages, which have not changed by much in the past year. However, this will perhaps change in Q1/2017, when we start rolling out organizations and roles for multi-user dashboard access.

In our opinion, React was easy to get started with even for a developer that had not used any of the modern front-end frameworks. When the application is complex and handles a lot of data, building with React requires an in-depth knowledge and an understanding of the inter-component communication. We had the following learnings regarding data management:

• Component data management: We started with AJAX and setState calls. Later, moved to a more Flux-like architecture, wherein the data is not stored in the components anymore. This approach gave us more predictable data flow and enabled us to create cleaner components, without a need to manage AJAX request lifecycle when mounting or unmounting the components.

• UI state management: Started with a lot of if-else statements in the components, which meant pages could not be linked or refreshed easily. We moved to routes to make the pages behave more like the traditional server rendered pages.

• Callbacks: We found it better to use routes and one way data flow wherever possible instead of calling back to the parent component. For example, we initially updated our conference graph charts by sending a new selection from the selector up the React tree to the closest container component, which passed them again down to the chart component. Later, we migrated this logic based on the URL (i.e., the URLs described the metric, selection), the components could then be completely decoupled. The selector only needed to care about updating the URL and the chart about rendering the state reflecting by the current URL.

Our dashboard code organisation and structure improved as more pages changed to React. Since React only provides view components, it means that structuring the non-UI parts of the app requires relatively more effort than the UI parts. Furthermore, building a large scalable and maintainable single page application (SPA) with React requires a lot of experience as it doesn’t really provide conventions for code organization.

At callstats.io, a fairly large call either with dozens of participants and lasting a few hours is about 2-4 GB in size. Fetching and rendering that data is an interesting challenge, especially if the data can be used by several components. If you are interested in handling large amounts of data in an UI, check out our jobs page and apply!