d3 charts within angular

[decio]

Hello!

I am curious to know other people's opinions on the following topic:

At work we are building a complex angular.js application that also has d3 based interactive charts.

The approach I generally follow for building charts in angular looks like this:

• On one side I have my own customized library of d3 reusable charts, that loosely follow the principles in: http://bost.ocks.org/mike/chart/ This bit is completely separated from angular and could be re-used anywhere else.
  
• On the other I create specific angular directives and pass them data and configuration objects. When these change (on watch) I simply re-update and re-call my reusable d3 chart functions from within these directives.
  

In my experience this approach works nicely and I can't see much benefit from changing things, but a colleague of mine has a somewhat different idea. In his opinion the whole d3 enter-update-exit pattern and most DOM manipulation should be handled directly by angular. Something in line with this post http://alexandros.resin.io/angular-d3-svg/

Now, although I can see his point here as a possible and interesting approach, I also feel very uncomfortable at the idea of going down this route for complex visualizations. One example I can think of is about how one would easily handle complex svg transitions within this scenario... something just doesn't feel quite right to me. Although I do admit that this scepticism could also be my resistance for trying something new and for leaving the path I feel comfortable with... so, does anyone else have experiences with this approach?

Again, I would love to hear other people's opinions on this. 

Many thanks,

Decio

 

[Kai Chang]

What is the advantage to switching to Angular for DOM manipulation on the charts?

--
You received this message because you are subscribed to the Google Groups "d3-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Max Goldstein]

Just about every D3+Angular resource is linked from here: https://www.dashingd3js.com/d3-resources/d3-and-angular

The fine folks at setosa.io have also had some luck with Angular and you can see it working there.

[Chris Viau]

The best pattern is the one you are comfortable with. I don't think coupling the charts library with the Angular digest cycle solves any pain point or performance issue. And it makes it more difficult to onboard new devs to work on the charts library if your D3/datavis expert also need to be willing to go down the Angular rabbit hole. I could argue that a decoupled charts library is also easier to test and debug, though Angular fan club would probably prefer the Angular ecosystem. Personally, I like to stay close to vanilla javascript and to D3 than to rewire my brain to a particular framework.

ChrisV

[Andy Thornton]

My 2 cents as somebody that integrates D3 and Angular daily is to stick with the approach you have now. Like Chris said, decoupling the chart from Angular, in my opinion, is a great idea. Since D3 is great at sticking to web standards, it should age well. However, frameworks and devs are easily distracted by shiny things. Angular 2.0 already looks like a pretty big departure from 1.0. I would rather have my charts independent of the framework so that when I'm asked to jump ship to a different framework, my charts can come with me without much re-work. I tend to let D3 do what it does well, and let Angular do what it does well. Seems to have worked well for me. So far :).

Andy

[Jim McCusker]

I've found that for visualizations, the main issue with angular for DOM manipulation is that it doesn't scale well. Angular would have to watch hundreds to thousands of variables within the model scope, which gets to deadly slow. I've seen this firsthand, and actually took a table that was being rendered using ng-table and had to make a reusable chart-type d3 function to render the table instead.

I inadvertently demonstrated this in my PI day blog post:

https://subluminal.wordpress.com/2015/03/14/make-your-own-pi/

If you take the JSFiddle from there and increase the number of points displayed at once, you'll see how slow things get.

I've had lots of success with your original approach (configure/watch/update a reusable chart) from within an Angular directive, so I'd suggest sticking with that unless you find that it doesn't work for you.

Jim

[decio]

Thanks Max,

Nice stuff on setosa.io, was not aware of it!

[decio]

Thanks Chris, 

I agree and think that keeping the 2 decoupled is the cleanest solution.

Decio

[decio]

Thanks Andy,

Yes, I do agree that that keeping the 2 decoupled is the cleanest solution.

Decio

[decio]

And thanks Jim for sharing. I agree.

Decio

[Ethan Jewett]

I work on this quite often as well and I completely agree with this point around keeping them decoupled. What I do find useful is to have my chart expose more granular update functions that I can then wire to specific changes on the Angular scope. This can be especially important in highly interactive applications where re-rendering the entire chart is expensive.

[decio]

Thanks Ethan,

Will give this a thought.

Decio