Designing javascript chart library

Question

I started coding a chart library on top of d3js: My chart library. I read Javascript API reusability and Towards reusable charts. However, I am NOT really following the suggestions because I am not really convinced about them.

This is how my library can be used to create a bubble chart:

    var chart = new XYBubbleChart();
    chart.data = [{"xValue":200,"yValue":300},{"xValue":400,"yValue":200},{"xValue":100,"yValue":310}];  //set data
    chart.dataKey.x = "xValue";
    chart.dataKey.y = "yValue";
    chart.elementId = "#chart";
    chart.createChart();

Here are my questions:

1. It does not use chaining. Is it a big issue?

2. Every property and function is exposed publicly. (Example: width, height are exposed in Chart.js). OOP is all about abstraction and hiding, but I don't really see the point right now. I think exposing everything gives flexibility to change property and functionality inside subclasses and objects without writing a lot of code. What could be pitfalls of such exposure?

3. I have implemented functions like: zooming, "showing info boxes when data point is clicked" as "abilities". (example: XYZoomingAbility.js). Basically, such "abilities" accept "chart" object, play around with public variables of "chart" to add functionality. What this allows me to do is to add an ability by writing:

   activateZoomAbility(chartObject);
   

   My goal is to separate "visualization" from "interactivity". I want "interactivity" like: zooming to be plugged into the chart rather than built inside the chart. Like, I don't want my bubble chart to know anything about "zooming". However, I do want zoomable bubble chart. What is the best way to do this?

4. How to test and what to test? I have written mixed tests: jasmine and actual html files so that I can test manually on browser.

Answer 1

My opinions:

1. It does not use chaining. Is it a big issue?

Not a big issue, but it does make it harder for others to use. Once a style gets implemented, people start to expect it, and when it doesn't work, some throw out your work as "broken". People don't read documentation.

Every property and function is exposed publicly. (Example: width, height are exposed in Chart.js).

One of the big advantages of hiding details is that, once you expose something, you have to support it when you rewrite the code to make it better. Another advantage is that, but making everything functions, you can react when a variable changes values without making the user change a variable and then call a function.

I have implemented functions like: zooming, "showing info boxes when data point is clicked" as "abilities". (example: XYZoomingAbility.js). Basically, such "abilities" accept "chart" object, play around with public variables of "chart" to add functionality. What this allows me to do is to add an ability by writing:

activateZoomAbility(chartObject);

One concept we are trying to avoid here is having conflicting function names in the global namespace. Look at the libraries that have plugins but only expose one global variable (jQuery is one, but by far not the only one, although it may have the most documented on how to make plugins correctly).

How to test and what to test? I have written mixed tests: jasmine and actual html files so that I can test manually on browser.

Look to see what others test, and how they do it. Honestly, there are a lot of broken libraries out there, so the better testing you do, the better chance you have of getting it right and not breaking anything on updates.

Thanks for offering code for others to use. Together, all of us can make a better web.