When visualizing data on the web, there are two things that we need to think of, the DATA and the DOM.
D3 is the go-to visualization library because it’s a flexible and data-driven approach to DOM manipulation; D3 does the complicated math so we can think more about data and visualization.
We use D3 for all our data visualizations like donut, area and bubble charts. In the example below, there are three large donut charts representing the percentage of social actions and referrals from different social networks. The charts are updated in real-time and clicking on each one displays a breakdown of the data by network also in real-time.
A screenshot of our dashboard, complete with real-time donut and area charts.
You can also see many smaller donut charts in the trending articles list. We use the donut charts throughout the application. They all function the same – the only difference is the data and size – so we wanted to make them reusable. We also work with a lot of real-time data so we have to be very careful about performance and DOM manipulation.
D3 is great for data visualization, but when dealing with complex applications your code can quickly turn into complicated spaghetti. I am not the only one who realized the problem. Sam Selikoff wrote an great article about getting started with Ember + D3 and sums it up nicely:
Ember’s opinionated architecture and design are exactly what I’d been looking for. I could now scaffold a project and be confident in its foundation. Interactive data visualizations can get tricky really fast, but I’ve already caught a glimpse of several Ember features that can smooth out these rough spots. I’m just starting out, but I’d like to share what I’ve learned about how these two technologies can work together.
With d3.json a callback function is used to wrap all methods that change the DOM elements. In large applications, this become unwieldy because it is hard to separate out concerns. With Ember you move the logic out of the callback and into Ember’s model, controller and view objects. If you are interested, read more about the benefits of Ember’s approach.
Without Ember, this quickly becomes a problem with real-time updates as DOM manipulations are computationally expensive and often event based actions send redundant signals. The Ember run loop is a solution to both these problems because it’s a smart queuing system that restricts DOM changes to only those necessary and transforms event based actions into streamlined method calls. It also gives you many ways to control when and how your data comes into the application, allowing you to debounce, throttle and delay when data gets to the DOM in a very clean and concise way. This is a major performance win with DOM-related changes and updates the DOM when it makes sense.
With HTML/CSS based charts, it’s easy to make charts responsive, but with SVG many properties need to be updated simultaneously, Ember computed properties and data bindings provide a perfect way to do that.
We use Ember Component to make charts reusable. Ember Components adhere closely to the W3C Web Components standard.
Web Components enable Web application authors to define widgets with a level of visual richness and interactivity not possible with CSS alone, and ease of composition and reuse not possible with script libraries today.
But until Web Components are standard in browsers, Ember is the best way to create modular reusable code. For additional details, please read my article about Reusable D3 charts with Ember.js Components.
One of Ember’s core promises is that it gives you a separation of concerns for DATA and DOM. You know where the code belongs, it makes it difficult for you to put it in the wrong place. In combination with D3, it allows you to create responsive, reusable charts and focus on telling your data story.
About the author: