Use ember-cli-d3-shape for dependencies instead of Bower
ivanvanderbyl opened this issue · comments
I've been working on a d3 addon which makes the D3 v4 NPM modules work with Ember. It's usable today, and allows you to load scales using proper imports import {scaleLinear} from 'd3-scale' for example. The benefit to this is you don't need to load the entire d3.js blob, or use bower for additional dependencies. It also tracks the new d3 v4 codebase which comes with a slightly more consistent API over v3.
Yea — I happened to come across your repository after I started building this. I'd be interested in adding it as a dependency, but it looks like it's doing more than just surfacing the respective d3 objects. Is this correct?
I'd be more interested in a separate ember-d3-shim addon that only exposes the underlying d3 modules that could then be consumed by this addon and yours...? Thoughts? (Happy to help there as necessary!) Would be nice to add some configuration so users get to pick which modules they want to include.
I'm also building this to support backwards compatibility with d3 v3 (which is probably why you see it in bower.json — it's only used in the test suites) as I'm going to be incrementally moving my app over so the scale helpers should work wether you're loading the modules for d3v4 or you already have the global d3 object loaded.
In addition, I have some further plans to expose the d3 primitives in a more template-driven style using helpers. D3 is pretty functional; Handlebars + Helpers are too. The only ember <-> d3 addons I've seen and used haven't really embraced the template in a way that I think allows for really good composability.
I'd be happy to discuss further as I think each of the respective d3 libraries could use a robust set of ember helpers (or components as necessary). I'm curious what your vision is too...
More or less, there's a few mixins included which I'll probably move to another repo. I'd like to start an official ember-data-visualisation project (with a better name) which is designed to utilise handlebars for expressing visuals, here's some discussion about this from yesterday ivanvanderbyl/ember-cli-d3-shape#4 (comment)
I'm going to be speaking about this at EmberConf, so it'd be great to gauge interest in such a project beforehand.
(First, I'm super looking forward to your talk! I'll be there.)
Well, consider myself interested in this project. I've had a few starts and stops with this problem over the last few years. The most recent took the drastic approach that maybe d3 is the wrong tool to use with Ember.
Since that, I've come to my senses, especially since d3 was split into modules. But, I still think that the approach on e3 (also not a good name!) is somewhere in the realm of the right one in that it tries to focus on the right type of composability and support for template-driven visualizations.
Based on that teeny little snippet into that plaid template, I think that our heads might be in the same place.
Is it worth trying to see if we can get a group together of interested parties at Ember Conf to see if there's some desire to make this ember-data-visuali(z|s)ation happen? I'd be interested. Sounds like Bryan would be too.
Awesome :)
Wow e3 has come a long way since I first checked it out. I'm not sure how I feel about doing scales in the template, I think it's confusing concerns a little.
I know that Mike Bostock really wants to drive the future direction of D3 as a library to use as the lowest level for building more powerful graphing tools, so at least if we use D3 as the basis the goals are nicely aligned. There's no doubt that most of the ways you see D3 written are an unmaintainable mess, especially the example code, so it'd be really cool if we could start to drive better examples using an Ember specific syntax. No doubt Ember provides all the needed features for loading and parsing data, and handlebars seems to be a very nice syntax for expressing component driven UIs. So from a visual perspective I think it makes a lot of sense to express the visual layers (elements and guides) as components, and probably do the scales and transforms in JS.
My main motivator for doing any of this over just using an existing charting library really comes down to expressiveness. It's really hard to build anything that looks and feels half professional when the only way to customise the appearance and behaviour is through abstract configs (see highcharts, nvd3 etc).
Heh yes visuali(z|s)ation, I'm running in Australian English, so chrome auto-completes to that :) I'll do a shout out during my talk to get people interested and find us during the break to chat about it.
It's really hard to build anything that looks and feels half professional when the only way to customise the appearance and behaviour is through abstract configs (see highcharts, nvd3 etc).
Yesssss. Exactly. Well, I look forward to discussing more.
In the meantime, I'm going to go ahead and actually do what your original issue suggested and use your addon for importing the d3 libraries. :)
(The builds are breaking in travis anyway and I haven't had the time to figure out why. This sounds like a better solution. ;) )
Awesome, let me know if you have any issues with it. My loader is kind of experimental, but I'm using it in prod without issue. I just haven't tried it in an add-on, but it should be fine.
I'll update the dependencies whenever Mike does (about once a week while it's still <1.0). But there's only been breaking changes once when he renamed the scaling functions.