Putting data first: state-driven app design for graph visualization

27th April, 2020

We took a radical approach when we built our graph visualization toolkit for React developers, and ReGraph is one of the few state-driven graph visualization solutions on the market.

Introducing ReGraph - our graph visualization toolkit for React developers
Introducing ReGraph – our graph visualization toolkit for React developers

The lessons we learned along the way are useful to everyone building graph visualization applications – React-based or not. In this blog we’ll share them, but first let’s take a closer look at the different application models and how they impact your visualizations.

Where does React fit in?

React is a popular front-end JavaScript framework. There’s lots to say about it (check out our popular blog on harnessing React Hooks), but the key things you should know are that it is declarative and component-based.

All of the information in a declarative application is held in a central place called state. To update the application, we just need to update that state.

Each React component is a self-contained UI element that figures out how to update itself each time the state is changed. Clever, eh?

Prefer to watch a video?

Kevin’s talk on this subject was recorded at our virtual JavaScript meetup.

Watch the video

JavaScript models – imperative vs. declarative

In an imperative app, data is an input for the chart and changes to the data are driven by the chart. In a declarative app, the data is changed, and the chart is merely the thing showing us the data.

A typical JavaScript-based graph visualization is imperative. The developer takes direct control of the chart and tells it what to do, for example, ‘run a layout’, ‘add this data’, ‘make these nodes red’.

In a state-driven, or declarative, graph visualization the developer changes the data in their application and the chart component decides how to handle the changes. You tell it what you want, not how to do it. The component asks questions like ‘is a layout needed?’, ‘what items are new?’, or ‘have any nodes changed color?’. Each of these questions is answered and then the component animates beautifully from the current state to the new state.

Let’s compare the two. In this demo, a user clicks the button to change the node color.

You can style chart items however you want

This is what’s happening in each model:

A table comparing the steps needed to execute the same interaction in imperative and declarative models

For such a simple scenario, the declarative model seems way more complicated. True, but let’s see what happens in a more complex scenario. Here we’re adding and removing data before running a layout.

ReGraph’s declarative graph visualization model is highly efficient in more complex scenarios

This time, the declarative model is about the same as for the simple example, but the imperative model is far more complex:

A table comparing the steps needed to execute the same (more complex) interaction in imperative and declarative models

As you can see, the declarative model scales much better. And by letting us make multiple changes at once (adding, removing, and running the layout in a single state update), we don’t have to think too much about the order in which we do things. This takes a lot of complexity out of our application.

Get started with our toolkit technology

Not using ReGraph yet?

Request a free trial

Filtering: Should I stay or should I go?

Filtering is an important part of any graph visualization application. Defining your own property-based filter logic means you can focus on the most interesting connections in your network.

Filter out the noise in your graph visualizations

Here we’re looking at web vulnerabilities, and filtering out the Adobe Flash ones to see what a ‘Flash-free’ internet will look like.

Our two application models consider filtering in exactly opposite ways:

  • In the imperative app, we create a list of all of the things we need to remove from the visualization and pass that list to the chart.
  • In the declarative app, we build a list of the data we want to keep and we pass this updated list back to the chart to take care of.

Managing large back-end queries is also easier because your front-end code doesn’t have to figure out what’s changed in the data. Just pass the new data to the chart component and it takes care of the rest.

Layouts: an action or a way of being?

Layouts are essential for untangling and understanding any network. The way we think about layouts is very different in a state-driven application.

Detangle your complex connected data to uncover hidden structures

In the imperative model, a layout is an action triggered either by the application or by the user telling it to ‘run a layout’.

In a state-driven application, a layout is instead a mode. As data is added or removed, the chart works to maintain the look of the layout, whether it’s a force-directed layout or hierarchy data displayed with the sequential layout.

Sequential layout works well for workflow or process visualizations and impact analysis

Paradigms: all or nothing

Whenever I talk to people about graph visualization, one question usually comes up: “Can I see all of my data on the screen at once?”.

If there are more nodes in your graph visualization than there are pixels on your screen, it's time to rethink
If there are more nodes in your graph visualization than there are pixels on your screen, it’s time to rethink

Our toolkit technology is powerful enough to handle your biggest datasets, but your users will get limited insight from seeing hundreds of thousands of items. Also, getting them to do the necessary aggregating and filtering is not the best use of their professional analytical skills. You’ll find more about this on our blog, including five steps to tackle big data graph visualization and how to visualize very large networks and still uncover insight.

Maybe this approach is based on the idea that data is an input for the chart, and that all changes to the data should be driven by the chart.

Let’s turn this on it’s head. Think of the data as the thing which is being changed, and think of the chart as merely the thing showing us the data.

Now we can work to design more intuitive graph visualizations which start with a small amount of relevant data, such as an interesting cluster of nodes or a specific question that needs to be answered. This is a recognized analysis technique: focus on a small amount of data and explore outwards, adding chart items incrementally. In this way, we provide users with tools to interrogate their data, rather than tools to sort through it.

Analysts often prefer to start small and focus on key items before expanding relevant data into the chart from the backend

But how does this help me?

Even if you don’t use React, the state-driven approach teaches us important lessons to help with future graph visualization projects.

Firstly, focus on what your data contains and the questions you want it to answer. UI and UX design is important, but don’t get distracted by the shape of the buttons your analysts are going to press. Let a graph visualization component take care of how to display things and handle new data, so you can pay attention to what insight you want your users to find and which threats they need to reveal.

Use our toolkit technology to build apps specifically for your users, your data and the questions you need to answer
Use our toolkit technology to build apps specifically for your users, your data and the questions you need to answer

And secondly, it is your data that makes your visualization unique. Lean into that and make sure that users can see the right amount of data at the right time.

Your choice: ReGraph or KeyLines?

Whether you choose an imperative model from KeyLines or a state-driven approach from ReGraph, you’ll give analyst’s the tools they need to bring their connected data to life. Request a free trial

More from our blog

Visit our blog