So if there's no differentiator why should I be interested in it? If you have a library that's entire purpose is visual and you show me nothing then that's a failure. I'm not going to clone a repo and spin up some examples just to see if they suck or are awesome.
indeed, first thought was how does it differ from classic d3 charts ? i like d3 a lot, but usually it takes some boilerplate code to setup charts. when working with multiple datasets the d3 commands look a bit confusing at times, so higher level abstractions are interesting to see
Yeah, but I think the point the author is trying to make is that whatever you can do with D3, you can do with this. But the responses just prove that 'love starts from the eye'
> Common API for getting and setting accessor functions.
This is a really good idea, and it solves the issue of coupling commonly see in d3.js examples, where the chart needs to know about the keys (properties) of the data.
I usually write accessor functions as part of my model to avoid this coupling but letting the chart component take in accessor is clearly a better approach.
yeah, this is the bit I liked. Personal taste: I'd prefer to see this implemented without extending a base class i.e. by composition rather than inheritance, seems more d3-ish to me.
Having worked with Bob and having him explain the "why" of the different transitions, the behavior of the charts combined with the look/feel really sell them to me. It's hard to compare other charting libs to this. That said, would be nice if they finally open sourced more of the better charts that were on the main applications of the company behind it.
I really don't like when subscribers get the instance as an implicit this instead of an explicit parameter. It makes code harder to read if you ask me.
Other than that nitpick, the examples given in the Readme.md are a bit too basic, the author maybe could show it off a little bit.
I found it much easier to reason about these libraries behaviour if I had one small interface from React to the lib. It makes updates also easier, no need to wait that the wrapper gets updated.
(One of the best thing about D3.js (as an approach, not only - a library) is "examples (with working code) first". First both in terms for priority, and exposure.)
> However, as somebody who greatly depends on the d3.chart framework, I’ve gotten concerned that support for the project has dwindled over the past several months. This has prompted me to write my own reusable charting framework,
Why not put that energy into contributing to the Miso Project?
25 comments
[ 3.3 ms ] story [ 74.3 ms ] threadNice site though, don't get me wrong
Basic Bar Chart (ES2015): http://jsbin.com/qopuwerixa/edit?js,output
Basic Bar Chart (ES5): http://jsbin.com/zutise/edit?js,output
Stacked Bar Chart (ES2015): http://jsbin.com/nifoxohuxa/edit?js,output
This is a really good idea, and it solves the issue of coupling commonly see in d3.js examples, where the chart needs to know about the keys (properties) of the data.
I usually write accessor functions as part of my model to avoid this coupling but letting the chart component take in accessor is clearly a better approach.
Other than that nitpick, the examples given in the Readme.md are a bit too basic, the author maybe could show it off a little bit.
I made an integration example a while ago: https://github.com/kay-is/react-from-zero/blob/master/16-adv...
I found it much easier to reason about these libraries behaviour if I had one small interface from React to the lib. It makes updates also easier, no need to wait that the wrapper gets updated.
(One of the best thing about D3.js (as an approach, not only - a library) is "examples (with working code) first". First both in terms for priority, and exposure.)
Why not put that energy into contributing to the Miso Project?
d3 is good. let's just use that you genius