More modular D3.js coding

Question

Consider the code snippet

let circles = svg.selectAll("circle")
                 .data(data)
                 .attr("cx", d => d.x)
                 .attr("cy", d => d.y)
                 .attr("r", 2);

The three lines attr-cx, attr-cy, and attr-r operate internally using the following pseudo-code:

foreach d in update-selection:
    d.cx = (expression)
foreach d in update-selection:
    d.cy = (expression)
foreach d in update-selection:
    d.r = (constant)

Now suppose that we want to do it differently. We'd like to instead run:

foreach d in update-selection:
    d.cx = (expression)
    d.cy = (expression)
    d.r = (constant)

by writing either

let circles = svg.selectAll("circle")
                 .data(data)
                 .myfunction(d => d);

or

let circles = svg.selectAll("circle")
                 .data(data)
                 .myfunction(d);

We might want to do this because:

No matter how fast the iteration control, it's still faster if we iterate once rather than three times.
The sequence of attr-cx, attr-cy, and attr-r is not just three statements, but a sequence of many dozens or hundreds of statements (that manipulate attributes, among other changes), and we'd like to isolate them into a separate block for readability and testability.
As an exercise to better understand the options available when coding in D3.

How might you isolate the triple of attr statements through a single function call?

Update

Towards Reusable Charts is a rare post from Mike Bostock suggesting a way to organize a visualization by separating the bulk of the code into a separate module. You know the rest: modularity facilitates reuse, enhances teamwork by programming against APIs, enables testing, etc. Other D3.js examples suffer for the most part from a reliance on monolithic programming that is more suited for discardable one-shot visualizations. Are you aware of other efforts to modularize D3.js code?

Does this answer your question? How to set multiple attributes with one value function? — SmokeyShakers
– SmokeyShakers, Commented Dec 30, 2019 at 16:01
@SmokeyShakers Not sure. Let me think a bit about advantages that would still be missing. — Calaf
– Calaf, Commented Dec 30, 2019 at 22:18
Is your first point necessarily true? Say you have 10 elements with 2 attributes each. You're proposing it's faster to iterate over the 10, then within each iteration, iterate over the 2 attributes. Why are you sure that's faster than iterating over the 2 attributes then, within each iteration iterating over the 10 elements. — SmokeyShakers
– SmokeyShakers, Commented Dec 31, 2019 at 17:24
@SmokeyShakers You are right with regards to each datum. Once the datum is a nontrivial, or "fat", datum, then perhaps there aren't that many of them for one to ignore every other countable compared to the data. Still, the idea is that we are not merely changing attrs, but we have a set of distinct manipulations within each fat datum. Within that set, we're not even iterating. It's simply a sequence of operations that we need to do/update. — Calaf
– Calaf, Commented Dec 31, 2019 at 17:35
Ha, thanks but I'm a base R dinosaur until extinction. No pipes and mutates for me. And where I'm from we don't mention certain bears and snakes. Maybe I'll put something on Observable and we can continue the discussion there. — SmokeyShakers
– SmokeyShakers, Commented Dec 31, 2019 at 18:18

Gerardo Furtado · Accepted Answer · 2020-01-02 02:57:48Z

TL;DR: there is no performance gain in changing the chained attr methods for a single function that sets all attributes at once.

We can agree that a typical D3 code is quite repetitive, sometimes with a dozen attr methods chained. As a D3 programmer I'm used to it now, but I understand the fact that a lot of programmers cite that as their main complaint regarding D3.

In this answer I'll not discuss if that is good or bad, ugly or beautiful, nice or unpleasant. That would be just an opinion, and a worthless one. In this answer I'll focus on performance only.

First, let's consider a few hypothetical solutions:

Using d3-selection-multi: that may seem as the perfect solution, but actually it changes nothing: in its source code, d3-selection-multi simply gets the passed object and call selection.attr several times, just like your first snippet.

However, if performance (your #1) is not an issue and your only concern is readability and testability (as in your #2), I'd go with d3-selection-multi.
Using selection.each: I believe that most D3 programmers will immediately think about encapsulating the chained attr in an each method. But in fact this changes nothing:
```
selection.each((d, i, n)=>{
    d3.select(n[i])
        .attr("foo", foo)
        .attr("bar", bar)
        //etc...
});
```
As you can see, the chained attr are still there. It's even worse, not that we have an additional each (attr uses selection.each internally)
Using selection.call or any other alternative and passing the same chained attr methods to the selection.

These are not adequate alternatives when it comes to performance. So, let's try another ways of improving performance.

Examining the source code of attr we can see that, internally, it uses Element.setAttribute or Element.setAttributeNS. With that information, let's try to recreate your pseudocode with a method that loops the selection only once. For that, we'll use selection.each, like this:

selection.each((d, i, n) => {
    n[i].setAttribute("cx", d.x);
    n[i].setAttribute("cy", d.y);
    n[i].setAttribute("r", 2);
})

Finally, let's test it. For this benchmark I wrote a very simple code, setting the cx, cy and r attributes of some circles. This is the default approach:

const data = d3.range(100).map(() => ({
  x: Math.random() * 300,
  y: Math.random() * 150
}));

const svg = d3.select("body")
	.append("svg");
  
const circles = svg.selectAll(null)
	.data(data)
  .enter()
  .append("circle")
  .attr("cx", d=>d.x)
  .attr("cy", d=>d.y)
  .attr("r", 2)
  .style("fill", "teal");

<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/5.7.0/d3.min.js"></script>

And this the approach using setAttribute in a single loop:

const data = d3.range(100).map(() => ({
  x: Math.random() * 300,
  y: Math.random() * 150
}));

const svg = d3.select("body")
  .append("svg");

const circles = svg.selectAll(null)
  .data(data)
  .enter()
  .append("circle")
  .each((d, i, n) => {
    n[i].setAttribute("cx", d.x);
    n[i].setAttribute("cy", d.y);
    n[i].setAttribute("r", 2);
  })
  .style("fill", "teal")

<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/5.7.0/d3.min.js"></script>

Finally, the most important moment: let's benchmark it. I normally use jsPerf, but it's down for me, so I'm using another online tool. Here it is:

https://measurethat.net/Benchmarks/Show/6750/0/multiple-attributes

And the results were disappointing, there is virtually no difference:

There is some fluctuation, sometimes one code is faster, but most of the times they are pretty equivalent.

However, it gets even worse: as another user correctly pointed in their comment, the correct and dynamic approach would involve looping again in your second pseudocode. That would make the performance even worse:

Therefore, the problem is that your claim ("No matter how fast the iteration control, it's still faster if we iterate once rather than three times") doesn't need to be necessarily true. Think like that: if you had a selection of 15 elements and 4 attributes, the question would be "is it faster doing 15 external loops with 4 internal loops each or doing 4 external loops with 15 internal loops each?". As you can see, nothing allows us to say that one is faster than the other.

Conclusion: there is no performance gain in changing the chained attr methods for a single function that sets all attributes at once.

You bring a lot of ideas. I regret that I didn't say "We might want to do this for any of the following reasons:". If each datum is itself a hierarchical structure, and not a rect or a circle, then modularity becomes the main objective, and it's saner to define a datum's enter/update/exit functions away from the D3.js logic.
@Calaf in my opinion, your edit (update) made your question worse: you're asking about modularity and reusability (and indirectly FP), but the core of your question is the performance of chained and repetitive methods. The way it is now it became a very confused question, almost impossible to answer.

Tim Hirst · Accepted Answer · 2019-12-31 09:21:27Z

-1

Does the .call() method of the d3 selection do what you're after? Documentation at https://github.com/d3/d3-selection/blob/v1.4.1/README.md#selection_call

I have sometimes used this method to define a more 'modular' feeling update function, and even pass different functions into the call() to do different things as required.

In your example I think we can do:

function updateFunction(selection){
    selection
      .attr("cx", d => d.x)
      .attr("cy", d => d.y)
      .attr("r", 2);
}

let circles = svg.selectAll("circle")
                 .data(data)
                 .call(updateFunction);

answered Dec 31, 2019 at 9:21

Tim Hirst

6244 silver badges19 bronze badges

Collectives™ on Stack Overflow

More modular D3.js coding

2 Answers 2

2 Comments

Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related