Create a plugin architecture (Formerly: Consideration for future: source splitting and plugin architecture)

lblb commented 10 years ago

Hi, This library is getting larger and larger, currently there are about 5000 lines of source in a single file, which is overwhelming even for experienced developers. I thinks it's time to start splitting the code into smaller logical units. I like how D3 is organized, they are concatenating all the small pieces to form a single js file as a result. It's not very difficult to implement, I can volunteer to do the it with C3 in a separate branch. Let me know.

Another aspect is that the library reached extent, so that core functionality should be identified, moving other functions into separate files as plugin modules. In this case end user could include only whats needed, or load modules on demand. Other libraries modularize even by chart type (if bar chart is all what you need, why waste bandwidth for other types), but I guess it would be hard to do the same with C3. However in my opinion these items can be good candidates for moving out:

Tooltip rendered. Someone could be able to replace the default one if needed and contribute results. Then library eventually will have multiple tooltips of different styles
Legend renderer. The core should provide legend renderer array of item information (color, datum, description, etc) and request a bounding box coords so that chart could be rescaled to fit everything. I would need this function very much in my project, as I'm not very happy how the default one works. The guy in #348 could also implement his own legend renderer the way required, without adding crazy features into the core.
Renderers for chart items. These are not existent now, but someone may wish to create fancy bars with shadows/gloss/gradients etc

To conclude all the said above would be a huge refactoring work. However if there are more people here who may want to get involved for making this library even better, then we may start planning things :)

yuvii commented 10 years ago

Hi, I'm the guy from #348. I totally agree. c3 is becoming something incredible. While most charting libraries are complicated to work with and very limiting, c3 manages to be powerful and still very easy to use and customize. It's the best library around, and I'm all in for making it better. I would like to contribute to this.

As someone who constantly meddles with c3's source code, I think most of your points are important, and would like to elaborate a bit more:

The minified version of c3 is currently around 80kbs, which is a lot.
The user configuration is not available throughout the entirety of the code, so currently it's impossible to pass information through the getConfig function to, say, the axis functionality (things such as tickSize are hard to customize)
This happens because almost everything is inside one function - c3.generate. Instead, I suggest we create an object called chart, and c3 will be the wrapper around it. That way, the refactoring will not make the previous code obsolete (it won't screw up users of the library if they update), yet it will allow better customization (anyone could override chart.prototype functions globally).

I would like to get involved. I think we should open an IRC channel or a discussion forum, github's issue's are mostly for... well, issues.

@masayuki0812 what say you? are you willing to accept our offer to help you?

masayuki0812 commented 10 years ago

Hi, Thank you for all your suggestions. I totally agree to refactor and change the architecture. I'd like to start working on this with your help. Thank you very much.

Let me summarize what you wrote as:

The code should be split into small units (the approach of d3 is desirable)
Some renderers should be moved out (tooltip, legend, chart item, etc)
Introduce an object called chart that allows better customization

For 1, I agree to do this by introducing d3 way and I'd like to keep its consistency with d3. In addition, I think we should also introduce vows as test framework.

For 2, I basically agree, but do you mean to split into multiple files as default? If so, I think c3 should be 1 file as default and can be removed if a user wants. These need to be able to removed, but I'd like to keep its simplicity. The way to remove would be running some script like make as d3 does, or custom download like some css framework.

For 3, it looks nice. I think this approach makes this library more extensible and would works well if the approach 1 applied.

What do you think about these?

And I think we should decide how to orginaize the code first. I think the approach of d3 seems one of the best way to do that as @lblb wrote. In addition, it would be reasonable to introduce same modules like smash and vows because of its consistency. What do you this about this?

@yuvii I'd like to discuss in one place as long as it works. Could you use this place for a while?

Thank you for all your help again :)

UPDATE: @yuvii Sorry, I started thinking we should google group because we can search topics more flexibly than github issue and here should be the place for issues that needs code fix. So, I created google group https://groups.google.com/forum/#!forum/c3js Please let me know if some settings should be changed (This is first time I use google group). Thanks!

masayuki0812 commented 10 years ago

I'll close this issue. Please visit google group topic for this instead: https://groups.google.com/forum/#!topic/c3js/M3Enybz1Q5k