C3: D3 4.0 compatibility

I just installed C3 on version 0.4.11-rc4 and D3 on version 4.0.0-alpha.29 and seems it don't work. :(

No it does not work there are some breaking changes in D3 4.0 and as such will require that c3.js calls be updated as well.

See here for reference:

version 4.0 means that it's a major release and not backwards compatible.

https://github.com/visfest/topics2015/blob/master/d3-v4.md

Interesting. Perhaps this is a good opportunity to rewrite much of the codebase to be more modular, such as I'm researching on my Webpack fork. Because everything is now using ES6 imports with Rollup in D3, it might be really smart to enable things like tree shaking with C3 through better use of modules.

That said, I'm nowhere near a JS design pattern pro — if you look at my fork, I've basically just imported each file as CommonJS, keeping to how the concatenation process builds the library. Any suggestions how to refactor to be more modular would be much appreciated.

I've been contemplating forking c3, I am using it heavily for internal tools and have actively maintained my own version of it. I've had to fix many bugs in it and unfortunately, I knew that any commits to this repo would go unaccepted.

Some of the things I've added are caching of attributes and selectors, this improved performance by two fold on the chart redraw methods and initial render. I've also had to add features like the capability to render gradient charts and better tooltips. Countless other undocumented fixes that I had to implement while using this library.

It would make sense to have c3.core and then all charts can be included to produce a super lean build, essentially only having the user to require the core lib and the charts they need, in my case I'm only using 4 of the charts in c3.

Not to mention the D3-4.0 improvements that could be included in c3. Anyway I can rant on about this library but it is one of the best ones out there just sad we cant contribute to this one.

I've played around with c3 and d3@v4. Some core d3 namespaces do no longer exist (d3.behavior, for example) so I couldn't get past that.

However, I managet to get some Rollup sweetness by replacing c3's concat and d3 smash tasks to use ES6 imports and exports. That doesn't leave much room for three shaking, but I'm not done tinkering.

@abacaj what I have done in the past was fork into an organization I made just to hold my open source projects and long term forks: https://github.com/huaofoundrie. If you're interested tell me and I'll give you admin permissions so we could mantain c3 nextgen from there

@abacaj and @amenadiel Hi! Please don't give up just quite yet — I'm planning on doing a huge tranche of work on the issue queue and elsewhere to really try and get 0.4.11 pushed out ASAP.

After that we'll really be looking towards getting a lot of what you've mentioned into the library for a new feature release, hopefully iterating much faster into the future. I'd love to get you two involved somehow (@abacaj, your thoughts re: c3.core are spot-on, I've been considering how to do exactly that the last few days); any chance you'd be willing to push your private forks somewhere so I can take a look and perhaps document/credit what you've done while resolving any issues you've encountered?

Thanks! 😄

@aendrew for sure, if you are willing to get this project moving again, then of course my first choice would be to contribute to the main repo.

@amenadiel That's fantastic — would you mind pushing your experiments somewhere? Would be good to see another take on how we could possibly modularise the codebase better. It definitely needs it, I'm so sick of continuously having to concatenate the source code...

I'll make a POC one of these days

looks like v4 was officially released. it would be great to see that update made available through c3

Agree with @travi, and I do confirm, that at least the very first "gettingstarted" example doesn't work with d3 4.0.0. It's ok for me now, I use suggested d3 3.5.0 version by bower, but would be great to have all version up to date and working appropriately.

@alundiak et al, it definitely will not work as-is with 4.0. D3 v4 has a totally different namespace and is in no way backwards compatible. Updating to v4 is a very non-trivial task.

I'm starting another approaches. Separating c3 into es6 modules might help.

My first approaches, using an ES6 shim for d3, is passing most of the test, but there's a lot of work ahest until we make folder structure coherent with module structure.

At least Chart, Chartinternal and Axis should be three separated modules. Some static methods of the aforementioned modules should become methods on their own.

I made a PR with the result of my experiments so far: https://github.com/c3js/c3/pull/1765

This doesn't include any change to d3. That change, which means using a minimal d3@3 skeleton and monkey patch it with d3@4 submodules, will be built on the basis of #1765.

are there any updates to this issues?

Without the update to Version 4 of D4 I can not use this lib anymore :/

@Niondir Out of curiosity, why is this the case? V4 doesn't bring any huge changes in functionality or stability to D3. Unless you're wanting to use D3 v4 elsewhere in your project (and C3's version is causing a conflict), the version of D3 that C3 uses shouldn't matter altogether that much... Granted, if I'm wrong in this assumption, please let me know as it might increase pressure to move the v4 upgrade forward.

Regardless, am looking at @amenadiel's extensive PR at #1765 this week, and may ultimately use that as the basis for upgrading to V4 for C3 v1. Please be patient everyone, this is probably the least-trivial issue in the entire queue right now. 😄

I just remember some issues with a missing merge() function on the selector.

@Niondir Okay, v4 has selection.merge, whereas v3 does not — but how does that impact your day-to-day use of the library? If you're not using D3 outside of C3, there's no tangible benefit to using v4 until we update the library. Don't get me wrong, there are a lot of good reasons for us to update to v4 within the context of developing C3 (custom builds and reduced library size amongst them), but from an end-user perspective I don't understand the desire at present. Any more information about your use-case would be most welcome! 😄

one issue that we've been wanting to take advantage of is datetime parsing in v4. v3 does not support millisecond with TZ offset fidelity for ISO-8601 dates, but v4 does. we do use the d3 formatters outside of c3, but can't take advantage of the improved parsing w/o loading both versions.

Cheers @travi, that's helpful. :+1:

If you installed just d3-time-format as a separate library and processed data with that, passing it in to C3, would that work? If not, that's a good initial user story for us to get started with.

i'll admit that it's been some time since i was deep enough in that part of our system, so i don't have my head around it quite as well anymore, but that seems like it would get us close.

i'm fairly certain the reason i backed away from updating our other formatters was because there didn't seem to be a way to swap the parser that c3 was using for parsing data.json passed to .generate(). if there were a way to get that much using the v4 parsers, i think that would be a good step in the right direction for our use case.

Just throwing my use case into the mix.

Our implementation requires the D3 Pack Layout which was updated to work much better in Version 4.

From the changelog:

The circle-packing layout, d3.pack, has been completely rewritten to better implement Wang et al.’s algorithm, fixing major bugs and improving results! Welzl’s algorithm is now used to compute the exact smallest enclosing circle for each parent, rather than the approximate answer used by Wang et al.

I'm looking into implementing C3.js instead of trying to write charts manually. This is a deal breaker for that switch though.

I'm not trying to be critical of C3.js at all, I fully recognize the task it'd be to upgrade to D3 V4. Just providing our scenario in case it helps make a decision on this particular issue.

Thanks guy!

@beaudesigns Cheers, that's very helpful.

I'm going to create a WIP pull request with what I've done so far with v1, and we can work off that until it's ready to merge. I'm admittedly crazy-busy with both the election and the book I'm working on, but would love it if people who are willing to help push this forward are able to contribute.

Is there any update on this? It seems as if the work for making C3 compatible with D3 v4 has stalled a bit.

What the status of this issue? I have Cannot read property 'format' error for D3 4.x

Same here, but we're willing to help migrating if maintainers tell us what's most valuable to them in the migration. Thanks again for the great work!
Cheers,

I'm working on this in #2246 . Still some fixes are needed, but looks working well basically.

Support for D3 v4 added by https://github.com/c3js/c3/commit/ccff119809de05a68ff3e33521a79566bf12b903 and should be available in the 0.5.0 release.

found one issue in Gauge when I updated C3JS to latest. Here it is https://github.com/c3js/c3/issues/2390