Graph Editor on the Web with react-digraph

Source: pikisuperstar

Editor’s Note:

Today, we will hear from Hartono on his team’s journey in facing (and overcoming) the challenge experienced by non-technical colleagues in interfacing with business rules that are often complex (by necessity) to maximize day-to-day business operations or decisions visually effortless with a graph editor.

Hartono Chandra is Web Software Engineer, whose responsibilities, include, but not limited to, implementing features and fixing bugs for Corporate Technology’s web-related projects as well as administering best practices.

Traveloka’s Corporate Technology (CorpTech) department creates business/finance-related tools that are used internally across Traveloka. One of our projects in CorpTech was the Central Fraud Platform (CFP). CFP is a business-friendly tool to manage flexible rules used to verify transactions/events against fraud without involving engineers.

Today, we will talk about one of the challenges we had faced (and overcome) for CFP and other related projects: creating a React-integrated graph editor that lets our non-technical colleagues interface with complex business rules visually.

The First Attempt: D3.js

After some research and discussions, we decided to use the D3 library for creating the rule editor that we called Decision Tree and here are the three main adoption reasons:

Popularity

D3 is the most popular JS library for visualizing any kind of chart or graph. Its GitHub repository has more than 100k stars.

Excellent Examples and Documentation

The D3’s examples page shows how powerful this library is, with easy-to-read code that guides how to use all D3’s features.

Flexibility

With D3, we can basically create any visualization we want. We can be assured that we will be able to implement any future requirement.

Figure 1. Decision Tree in CFP built using D3.

And here are some of the features of the graph editor we built with D3:

1. Basic Node and Edge rendering.
2. Node and edge creation.
3. Editing modal view/window.
4. Node and edge removal.
5. Enhanced view with zooming and moving around the view.
6. JSON format support for saving, exporting, and importing.

Enter react-digraph

The next project after CFP in CorpTech that utilizes a graph editor is the Reconciliation Tools (Recon). As the name suggests, Recon is a tool to automate/reduce the manual work for reconciling two data sources, which are created using the data source editor.

In Recon, we didn’t want to waste time on building our own graph editor again using D3 just like for CFP. That’s why we searched for an alternative library that is complete, adequately customizable, and solidly React-integrated. We found and gave react-digraph a try based on the following four reasons:

Maintained by Uber

Being backed and maintained by a popular and big company gives confidence for using the library. The repository is also popular with >2k stars.

Easy to Use and Quick Setup

By following the code examples in the repository we can get a complete graph editor running in just 15 minutes.

React-based

We have been using React on most web projects in CorpTech, including CFP and Recon. So it just fits our tech stack perfectly.

Feature-packed

React-digraph includes all the features we needed to implement on CFP using D3, including those that we think would be nice to have in the future.

Figure 2. Recon tool’s Data Source editor

Recently, we have a project in CorpTech called the Centralized Journal Converter (CJC). CJC is a tool to convert financial reports into journal format (GL). We have this Journal creation in the form of Directed Acyclic Graph (DAG). The graph editor’s requirements are similar to the Data Source editor of Recon. So, we built the CJC inside the Recon tool to reuse much of the code.

Migrating D3.js to react-digraph

Over time, the CFP project got bigger and more requirements were added. At one point, we felt that we had spent so much time maintaining the graph editor and fixing bugs, that we ultimately decided to migrate our graph editor codebase that we created with D3 to react-digraph. We wanted to (re)focus our time and energy on building features instead. Here are two reasons for our migration:

Steep Learning Curve

The first version of CFP was built with relatively little experience and expertise as it was new for everyone in the team. Combine that with the steep learning curve of D3, and we can only move forward resulting in a buggy code that we have to keep fixing.

Underutilization

D3 is a really powerful tool, with extensive features and utilities. After a while, we noticed that we hadn’t been using D3 to its full potential. Our graph editor is actually simple and we only used very few of D3’s features. In fact, at one point, we even thought of rewriting the graph editor without D3, just with plain React and SVG, and made a basic working demo too.

Also, our particular use case just didn’t maximize the benefits from D3 and React integration. Our codebase is React-based. But, our graph editor used D3’s rendering routine instead of React’s, which led to some confusions and maintainability issues.

Figure 3. The new CFP’s Decision Tree after the migration

From the above reasons, it was clear that it wasn’t D3’s fault that led us to this migration. D3 was simply not the right choice for our use case.

After the migration, we observed these four changes:

1. We removed around 3,000 lines of unneeded code from the old graph editor.
2. The new graph editor is smoother and more performant especially at high node count, as we didn’t do any optimization on the D3’s version.
3. All previous graph editor’s features were preserved as they came built-in in react-digraph.
4. React-digraph has many more features that we might enable in the future, like multi-select nodes/edges, copy-paste, etc.

Is react-digraph perfect?

React-digraph is by no means a perfect solution. Here are some of the cons and our consideration.

React Dependency

This library only works with React, so if you are not using React, then this library is simply not for you. In our case, it actually fits our tech stack perfectly because we have always been using React on almost every web project in CorpTech.

React-digraph’s Bundle Size

It has D3 and others as dependencies at 108KB minified + gzipped (according to bundlephobia). We don’t care too much about the size because CFP and Recon are the tools that are used internally.

Figure 4. React-digraph bundle size according to bundlephobia.

Performance on Extreme Node and Edge Count

React-digraph actually has an excellent performance, at least far better than our own D3-based graph editor. But, for a really high node and edge count (about >1000 nodes), then even react-digraph will have performance issues, mainly because it is based on SVG. If you need to have really high node count, then we think you should use a Canvas or WebGL-based solution.

Among CFP, Recon, and CJC in the production environment, the most nodes we ever have in a graph was 251 nodes on CFP. Yet, we didn’t see any graph editor’s performance issue . So, it is fine for our use case.

Not built for Mobile/Touchscreen

The default controls of react-digraph do not work on touch input. For our case, we don’t need touch input support so we are fine with this.

Documentation on Some Features could be better

After we migrated from D3 to react-digraph, at one point, we had a requirement to basically change the content of nodes and edges. React-digraph provides the renderNode, renderNodeText, and afterRenderEdge props for this purpose, but we found little to no documentation about these props. We need to look at the source code of the react-digraph to figure out how to use these props, how to apply the default shape based on NodeType, getting the stylings, etc.

Figure 5. Change to CFP’s Decision Tree condition to be inside the edges instead of nodes.

Conclusion

Today, we are using react-digraph on three projects in CorpTech: CFP, Recon, and CJC. The main benefit of react-digraph is it is a complete package with features that already fulfilled most of our needs, and it also integrates perfectly with our tech stack.

We decided to migrate from writing our own graph editor with D3 to react-digraph because we think it is very inefficient to spend so much time on maintaining our own graph editor, while react-digraph already provides all the features that we need (and more), with fewer bugs and better performance.

The CFP, Recon, and CJC tools are being used in production environments, with 251 nodes as the highest node count in a graph.

If you are interested in react-digraph, you can visit their GitHub repository. And if you are also keen on more details about our projects in CorpTech, stay tuned as not only will we have more related blog posts in the future, but we’re also hiring.