Should be published on npmjs.org

[mythmon]

No description provided.

[knownasilya]

I'm surprised this issue is still open 😄.

[jwalton]

+1

[knownasilya]

... it's so simple to do, and will only help it grow. cc @jugglinmike @iros

[iros]

We agree. It's almost ready =)

-- Irene

On Fri, Jul 11, 2014 at 12:56 PM, Ilya Radchenko [email protected]
wrote:

... it's so simple to do, and will only help it grow. cc @jugglinmike
https://github.com/jugglinmike @iros https://github.com/iros

—
Reply to this email directly or view it on GitHub
#56 (comment).

[jebeck]

+1

[jebeck]

@iros Is there an update on this and/or further development of d3.chart in general? Are there plans to continue its development and support? (Pretty please?) I notice there haven't been updates for many months...

(We're using it in production for one of our visualizations at Tidepool. Would love to expand our usage, but wondering about the long-term...)

[knownasilya]

I think everyone is wondering..

[nicksrandall]

I too have used d3.chart in production code and am sad that support for it has seemed to dwindle.

Because I depend on it so heavily, I have "re-written" this framework in JavaScript 2015 (ES6) and made it available on Github. I have also added a few features that I found myself wishing d3.chart had (like pre and post draw hooks). I would love some feedback from the community if anybody was interested in looking at it.

My team and I have built nearly 100 data visualization components using this framework and plan on "open sourcing" them in the future.

Find me on twitter if you have questions and I'll do my best to answer them.

Project Site

http://kotojs.org

[knownasilya]

@nicksrandall having 100 components opensourced would help this project continue. I would love to see your fork merged into the official repo.

[jugglinmike]

Hey folks!

Thank you for your concern about d3.chart's future. We (Irene and Mike) wanted to respond to your various concerns and address where it's going.

There's been no activity on the master branch in about 10 months, but we haven't forgotten about the project! We are still regularly using d3.chart in production, making charts and reflecting on potential improvements. (If you're curious, you can see our most recent work with it for the Stereotropes project.). Some of our attention has been focused on more indirect improvements. Following the last release of d3.chart, we focused on spanning changes to documentation across the Miso project. The result is that the Miso Project web site docs now source directly from the various projects' source code. We hope this pays dividends into the future!

We just today learned about Koto.js, actually. That project tends to duplicate the work we've started here, which is only concerning because we do intend to move forward with d3.chart. We share @knownasilya's interest in avoiding fragmentation, but this will require additional discussion since Koto.js has diverged in non-trivial ways. Some of the issues addressed by that fork are things we have been thinking about for some time, we definitely appreciate the need for more hooks (see gh-78) and accessors (see gh-67). We want to implement all features in a way that is reliable, consistent, and generalized (this is especially thorny for "after draw" hooks because "draw" operations frequently include asynchronous transitions.

@nicksrandall - we'd love to help you release those components as d3.chart... charts. Presumably some things would need to change about d3.chart first; if this sounds good to you, let's talk about how we can make that happen (either in this issue or in feature-specific follow-up issues).

Over the next week or so, we'll be checking back in on the issues we've allowed to go stale (sorry about that!) and compiling a roadmap for version 0.3.

[jebeck]

Thanks for the thorough response @jugglinmike! I also +1 avoiding fragmentation.

[jwalton]

If you want people to use this, you should push what you have here, right now, in this repo, to npm. I abandoned chart.js a long time ago, because I had no reasonable way to pull it into my project; I can't just copy-paste the JS file into my project because my project is spread across multiple repositories, so I'd end up with multiple copies of chart.js in my client-side browserified JS files; it's a non-starter. If it's "not quite ready yet", that's fine; semver says that so long as your major-version number is 0, you can change whatever you want. Even after you wander into 1.x.x territory, you can change the API radically so long as you bump the major version.

[jugglinmike]

Excellent point, @jwalton . My initial hesitation was the library does not export CommonJS module, and I got bogged down with a much larger problem related to that. Although we should still switch to UMD, the module's format is orthogonal to its presence in any given package manager. (Especially apparent due to the jQuery foundation's recent endorsement of npm as a repository for jQuery plugins)

https://www.npmjs.com/package/d3.chart

Sorry we missed the boat for you, Jason.

[knownasilya]

yay for the push!

[jebeck]

+1!!!

::happily goes off to update package.json files everywhere::