3

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.

2

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.

  • Thank you for the reply. I think the purpose of the library and resource constraints are also big issues. My purpose is to use the library internally for our startup. Also, I am single developer and chart library is necessary but not the main focus of our project. I did not follow chaining and exposed all variables. This allowed me to do stuff quickly and customize easily. I believe, this project definitely won't make for a good public library. I wish there was some third party chart library on top of d3 which was reusable and totally customizable and extensible. Thanks for the reply! – coolscitist Jun 3 '14 at 4:55
  • In that case, you are doing just fine. Good luck to you. – Guy Schalnat Jun 3 '14 at 7:04
  • Yeah, not the best solution but works for our use case. But still would like to know if there are better solutions already built (on top of d3js). It seems like reusability and customizability are conflicting interests. – coolscitist Jun 3 '14 at 8:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.