Support for multiple date adapters

[joshkel]

Feature Proposal

While investigating a bug report regarding date/time handling in a Chart.js plugin, I realized that properly testing the plugin's date/time support would benefit greatly if the test suite could register more than one date/time adapter. As far as I can tell, Chart.js doesn't support this.

This would rarely be of use outside of writing libraries for Chart.js; however, reducing the required use of globals and singletons and increasing flexibility seem like worthwhile goals in general. (For example, I appreciate that Chart.js's plugins system lets you use plugins on a per-chart basis as well as globally enabling them.)

Possible Implementation

A designed-from-scratch interface might look something like this:

• Each date/time adapter module exports its adapter class as well as automatically registering it as the default Chart.js date adapter when imported.
• Individual charts can import the adapter class and pass it to the chart using a new option - for example:
  • Instead of passing adapter options via the adapters.date option, a caller could initialize an adapter instance itself and pass it somehow - maybe via adapters.date (with Chart.js checking wither it's an options object or adapter instance via duck typing), maybe via some new adapters.dateInstance option or similar.
  • As a new top-level chart option, parallel to plugins, a caller could pass a new date adapter class (e.g., { type, data, options, plugins, adapter: { date } }).

Given backwards compatibility constraints (in particular, the desire to work with existing third-party adapters), the following approach might be better:

• Existing Chart.js time adapters already provide an _id member that's commented as "DEBUG ONLY". (See, e.g., here. Unfortunately, of the listed adapters, chartjs-adapter-dayjs-4 and chartjs-adapter-spacetime don't provide an _id.) Build off of that to allow multiple adapters to be registered and accessed by that ID.
• Whenever an adapter registers itself, core.adapters.ts maintains a registry by _id of each adapter as well as registering it as the default.
• Callers may request a particular adapter via a new adapters.dateId option or similar.

Since the only listed adapters that provide an _id are those within the chartjs GitHub organization, the backwards compatibility design may not be much of an improvement - Chart.js's provided adapters could be updated to export their classes for the designed-from-scratch approach, and most third-party adapters would apparently have to be updated regardless.

[kurkle]

Just my 5 cents about backward compatibility; I would not worry about the existing adapters that much - those are trivial to update as there are just a few. I'd be more worried about users, and maintaining compatibility with existing configurations.

[joshkel]

Thanks, @kurkle. Either approach should be backward-compatible from the user's perspective. If you're not worried about existing adapters, then my personal suggestion would be some sort of per-series adapters.dateInstance option (but you all have more experience with the Chart.js API design than I do).