Looking towards next major release

[kum-deepak]

This library is popular, works well, and has been in production use for many years. The two previous versions focused on upgrading to the latest d3 and converting it to ES6. In the process, quite a lot of tooling got upgraded as well. All these facilitate further refactoring to be easier.

Key guiding principles:

• No existing functionality should be dropped.
• Some of the syntaxes might change - however, compatibility should be maintained as far as possible.
• The newer syntax should not be more cumbersome than the existing syntax.
• Documentation should go better.

We ourselves want to expand our usage of this library. For that we will like to make the following simpler:

• Using the library with a remote data source.
• Saving and restoring filter states for the dashboard.
• Using a single standalone chart without crossfilter.
• Adding new chart types.

I see separating concerns as the key in achieving the goals:

• Data sources
• Managing filters
• Capping
• Ordering
• Existing Mix-ins
• Chart rendering
• Chart redrawing

My PoC in dc-js#1665 makes me believe that quite a lot of it is feasible.

An interesting case will be to see if the Row and the Pie charts can share more.

Some items that I think can be taken up:

• Moving to Typescript - this will help us in improving code quality (type checking, public/protected/private members). This library will be inputs that are not simple values or functions (like an Object with several methods) - the Typescript Interface definition can act as good documentation. With >ES6 as the output target, the output will almost be like the current ES6 code. Source maps keep the debugging the browser against the original code possible.

• Allow saving and restoring filter state (to from JSON probably).

• Quite often there is a valid case of using the same dimension in more than one chart. Currently, the filter state is maintained at the chart level but applied to the dimension - which causes issues. It seems possible to maintain it at the dimension level.

• Chart Group can become a class so that each of the Chart Group is an instance.

• Split Filters into independent classes, inheriting from a Common Interface.

• Consider creating a simple filter class that implements the Filter interface, consider creating a filter list class, which itself implements Filter interface.

• Consider making all util functions as top-level functions - bundlers are going to be happier. Remove usage of pluck.

• Reconsider filter printers.

• Depending on how much compatibility is required - compat code can be moved outside and be applied on top of the new code. We might consider creating two bundles - one only with updated API and one with compatibility API.

I am reasonably clear on each of the individual tasks. When we reach an agreement I can start work.