Plotting the first point of the Feedzai Charting Library.

Between July and August, I had the opportunity to join Feedzai’s 2019 summer internships as an Engineering Intern. I worked with the Data Visualization folks at the kickoff of the Feedzai Charting Library.

Feedzai Charting Library — I think you already have a glimpse of what this project is all about just by the name. Data is at the core of Feedzai and their visualization provides an effective way of communicating… but why would Feedzai care about creating its own charting library? Let’s look at some of the macro reasons most supported by the term “Library” rather than the term “Charting”:

Although briefly presented, these points summarize the motivation for this modest venture quite well. They are a bit “general”, but in a way, they were born purely from our context — if you have a few different or complementary thoughts about creating a library, in this case, a charting library, feel free to share them in the comments!

From this concept, many questions arise regarding the scope of the library: what charts to include, what level of customization to allow, what technologies to use, and more. We have a jungle full of possible paths and traps. And when those traps are activated, they unleash an avalanche of rocks that threaten to bury us. However, instead of rocks, we have pie charts… in 3D. So which way should we go?

We thought a good starting point would be to expand the React UI Component library used across Feedzai products with components dedicated to different types of charts, and to define these charts in Vega.

At first glance, it seems we have somewhat blurred platform-agnosticism. However, Vega, as we will talk about later, is very flexible and the idea of a repository with visualizations that everyone can contribute to and use will not be forgotten (#BabyStepsToGiantStrides). For now, let’s dig into the first steps.

Since the start of this project is intrinsically associated with the internship, it becomes interesting to talk about both at the same time. First things first: the first week of the internship was devoted to onboarding, getting to know Feedzai from the inside (and in terms of Data Visualization), and learning about Vega. It was crucial to get to know Feedzai better before I started writing any code whatsoever because this library must be created and adopted smoothly. It was like visualizing before the visualization (mind = blown?). The next (approximately sequential) steps involved the following actions:

Of course, the internship didn’t follow this so linearly; it obviously passed through an activation function. Overall, things proceeded at a good pace, even with some winding moments. During these two months, I followed what I call a DAAAG (don’t confuse it with a DAG, Directed Acyclic Graph, please). DAAAG stands for “Directed Absorption, Application, Assessment Graph” and summarizes the methodology I adopted.

Starting with “Absorption”, I tried to learn as many things as possible to gain the minimum confidence needed to apply (“Application”) my learnings and start the work required to meet the goals for this internship.

After completing small chunks, the “Assessment” node would arrive and, with more calm and constructive criticism, I tried to understand if what I did was good, or if I should implement some changes. This way, I wasn’t so stuck on how to implement something, I just let it happen. With the gained knowledge and experience, my critical eye became a little sharper, and the next steps became a little clearer, mitigating the impact of a bad idea and ensuring that every day I made at least a little bit of progress on the roadmap. However, as might be expected, this route was not fully sequential. Over time, it was necessary to jump between nodes in this graph, as I had to check the Vega documentation to learn something new or implement a quick change during the evaluation process to be able to quickly test a new idea, for example.

You might wonder why we decided to start with the histogram as the first visualization for our library. Good question! There were two reasons:

We’ll get back to these points later, but for now, let’s look at the technologies used besides our old friends “pen and paper”.

Regarding the stack used during the internship, the following technologies and libraries stand out:

First of all, React is… well, React is React. It is one of the most widely used and known JavaScript libraries for building user interfaces today.

In order to ensure the created component worked as intended, we coupled a test suite. With the help of Jest and Enzyme, a set of unit and snapshot tests were defined.

Finally, it’s worth mentioning the use of Lodash, a JavaScript utility library with lots of methods to solve certain needs in a productive way (like performing a deep comparison between two objects to determine if they are equivalent), and Storybook. Storybook provides an excellent sandbox to mock different components (and different states and/or props, for example) and expose them in a pleasant way for the stakeholders. Basically, we end up with a kind of wiki that we can easily browse and check the different available components.

In short, I think the stack used can be summarized as “JS²” — Je Suis JavaScript.

It is finally time to look at the “dirt”! In this part, I will share some of the details of what we managed to achieve, the problems we faced, and the doubts that remain. I’ll also share some ideas on possible vectors worth exploring in the future.

First, the Vega specification, that is, the JSON file, contains a basic histogram with some artificial data. Thus, it is ready to be used in any of the supported platforms, and we allow anyone interested in testing the Vega specification to see a simple, out-of-the-box example. Therefore, one of the responsibilities of the React Histogram component is to adapt and customize this Vega specification.

Before delving into some of the details of the solution’s design, I think it is useful to first give an overview of the Histogram component. This component is a class component, with multiple props, that leverages some lifecycle methods. It is important to note that we used refs to facilitate the identification of the container (<div>) in which the histogram is embedded. This allows us to capitalize on the “commit phase” (as we can work with the DOM) to “mount” and “update” the chart (according to the original and new props, respectively). Note that in the “render phase”, we just add the empty container that will later contain the chart. A new container, as well as a new chart, is rendered every time there is an update.

These are the main features of the Histogram component:

Although a histogram is one of the most widely used and well-known chart types, our component needed to handle challenges beyond styling a simple “set of bars”:

On the other hand, while it was not difficult to integrate React and Vega, we were walking in uncharted territory. There aren’t many examples or use cases that combine React and Vega, and little discussion on possible approaches (as well as advantages and disadvantages). The best (in my opinion) blogpost found, written by Peter Beshai, dates back to 2016 and is just a simple proof of concept. It doesn’t cover component creation to integrate into a UI library used in production.

Looking at the Vega roadmap, there are two features that we are really looking forward to: Animations and Labeling.

Regarding data, Vega has a well-defined data model which uses tabular data. This should be kept in mind, as the data that is passed to our component is already transformed and may no longer be in its original shape. Therefore, we may have to reshape it. This happened when we tested the new Histogram component in another Feedzai library to evaluate the possibility of integrating it in the future. Since the data feeding the histogram did not fit a tabular format, it was necessary to make some changes to the calculations and objects to ensure that the histogram received the data as expected.

Finally, I would like to share some backlog ideas in the hope that it gives you a glimpse of possible future steps.

Since only unit (and snapshot) tests were implemented, it would be important to consider other types of tests in the future (as well as assess their possible interaction with React and Vega), such as integration tests and end-to-end tests, but particularly some visual regression testing (unit tests have a very specific low granularity and don’t see the bigger picture).

Just two months of work and so much to cover! I hope the previous sections have been clear (and fun) and that you now have a “mind chart” full of ideas for the future.

These are perhaps the most important things I carry with me from my internship:

This is the easiest part to write. First, I want to thank Feedzai, as an organization, for this amazing opportunity and all the support. It was two months of extremely gratifying work. From the first contact, I felt a warm atmosphere (which I believe will continue as long as I do not commit any fraud). In particular, I would like to truly thank the three people who supported me most during this period, namely Beatriz Jorge, Liliana Fernandes, and David Polido. You kicked off the idea of the Feedzai Charting Library and, since my interview, you have been present not only to help me and contribute to the project, but also to talk, discuss Data Visualization, and provide me with other complementary opportunities during the internship. It was a really good experience and it allowed me to greatly enrich my “dataset” for the future — thank you very much for everything! Finally, I would also like to thank Krisztina Nagy and Indigo Wilmann for the careful feedback that allowed me to reach the best possible version for this blogpost. Otherwise and alone, this would not be possible.

Related posts:

Probably one of the crucial considerations when planning a private wireless network is the use of licensed or unlicensed channels. Most cellular devices operate on licensed spectrum, although some…

Do you ever have those days where your inner critic is out of control? My week started like that. Bitch Ruth, as I like to call my inner critic, was loud. I’d woken up with the Monday blues…

Kau tak perlu tanyakan mengapa semua abu itu hilang.. “Ragu yang Berlalu” is published by Cadenza Travis.