Patternfly charts - unmaintained dependency

Hello everyone,

Currently Patternfly react is dependent on another library that implements C3 charts in react, react-c3js.
This library appears to be unmaintained for a significant amount of time, and there is very little activity there over the last year.

This causes us a problem of getting the latest features of the latest version of C3. C3 is now at 0.6.8v, while react-c3js is at 0.4.11v (of C3). At the beginning of July I have opened a pr to react-c3js to update it, but there is no response form the single maintainer.

At this time, on the foreman project we already encountered the need of the latest version when using Patternfly Bar chart and Line Chart. While at this point of time it may not be the most urgent issue, it can be a bottleneck in the future, as charts are significant components on many enterprise applications.

Should we switch to another library that implements c3 in react? From a (very) quick look I could find some other C3 react repositories, but only one with recent activity in it - react-c3-component. (I did not yet looked into it, just saw it has some activity). Or if no alternative, should we maybe have our own fork of react-c3js?

What are your thoughts?


Just my two-cents - maintaining a fork is probably not something we’d want to default to. It might be nice to evaluate those other libraries and see if we can switch to those instead. Wonder what @priley86 and @jeff-phillips-18 would think about it.

hey @egilman and @dgutride - i think this is a good topic. It does seem that C3 is largely unmaintained now, however in most cases it is just a lightweight wrapper around D3. If you are building a PF3 based app, I think it is important to stay consistent where possible until we have clear PF4 guidelines on this.

That being said, I like the direction a lot w/ PF4 exploring a new charting extension library. @dlabrecq 's summary about Victory is spot on:

Victory is a very composable library which should work well for React products. I would consider this for future implementations if possible. There are some good examples of this in project koku already:

@dgutride - I think you can probably share more context w/ @egilman as she gets closer to PF4.


1 Like

does this mean we can drop the c3/d3 dependency (or make it optional?) it is a fairly large portion of the js bundle.

hey @ohadlevy - we have noted this in the past as well. C3/D3 makes up nearly half of the dependency weight on patternfly-react dependency if treeshaking/esm modules are not used. The patternfly-react dependency is safe for tree shaking though. I know of a few apps doing this right now: (could also be updated to using Create React App 2.0 now)

I think it is really a question to the community though - should we take time to move C3/D3 to a separate package? Is it worth a breaking change at this point for PF3 (to pull charts out)? I think we can easily do this if people would like this.

I think we should definitely try to keep Charts in a separate package in PF4 (just learning from this experience). The external dependencies/3rd party libraries should probably be kept to a minimum in the react-core library.