Chart.js: State of Chart.js & V3.0

[etimberg]

beta is available

We're proud to announce that Chart.js 3.0.0-beta is now available. Get it with npm install chart.js@next --save

• Release notes
• npm
• Migration guide
• Docs
• API
• Samples

Overview

Chart.js 3.0 introduces a number of breaking changes. Chart.js 2.0 was released in April 2016. In the years since then, as Chart.js has grown in popularity and feature set, we've learned some lessons about how to better create a charting library. In order to improve performance, offer new features, and improve maintainability, it was necessary to break backwards compatibility, but we aimed to do so only when worth the benefit. Some major highlights of v3 include:

• Large performance improvements including the ability to skip data parsing and render charts in parallel via webworkers
• Additional configurability and scriptable options with better defaults
• Completely rewritten animation system
• Rewritten filler plugin with numerous bug fixes
• Documentation migrated from GitBook to Docusaurus
• API Documentation generated and verified by TypeScript
• No more CSS injection
• Tons of bug fixes
• Tree shaking

In this issue we'll maintain a list of committed, nice-to-have, and proposed features for v3. Feedback from the community will help shape the prioritization for v3.

Committed Features

• Rollup configured for ES6+ babel translation (#6555)
• Remove custom (https://github.com/chartjs/Chart.js/pull/6605)
• Remove all deprecated code
  
  
  
  • Most deprecated code has been removed. However grep -ri backward src still returns a handful of results. Also need to search the code for TODOs
  
  
• Prefix all private methods with underscore
• Make ticks objects (https://github.com/chartjs/Chart.js/issues/5019) (or not? should we revert? see https://github.com/chartjs/Chart.js/pull/6791)
• Remove moment from package.json (https://github.com/chartjs/Chart.js/pull/6745), move the moment adapter to an external project, and remove the rollup optional plugin
• Remove zeroLineIndex feature and replace with function based axis properties (https://github.com/chartjs/Chart.js/pull/6697 & https://github.com/chartjs/Chart.js/pull/6700)
• Change require to import, adopt ES6 classes, use const / let, etc.
• Scale cleanup
  
  
  
  • Change axis options from an array to an object keyed by ID (https://github.com/chartjs/Chart.js/pull/6773)
  
  
  • Cleanup getPixelForTick (https://github.com/chartjs/Chart.js/issues/6715)
  
  
• Performance Improvements
  
  
  
  • Accept data in a format that doesn't require parsing (https://github.com/chartjs/Chart.js/issues/6696)
  
  
  • Improve performance of finding hovered element (https://github.com/chartjs/Chart.js/issues/6716)
  
  
  • Split _options out of _model. Creating _model is expensive right now, since it's done for each data point. However, _options does not need to be recreated for each data point unless scriptable options are being used. Thus by just using _options directly instead of copying it into _model we would be much more performant (https://github.com/chartjs/Chart.js/pull/6845)
  
  
  • Reduce number of objects created (e.g. _view and _model) when animation is disabled (e.g. https://github.com/chartjs/Chart.js/pull/6710).
  
  
• Make beginAtZero default be true for bar chart (https://github.com/chartjs/Chart.js/issues/5939)
• Cleanup options (https://github.com/chartjs/Chart.js/issues/5233)
  
  
  
  • Remove element options and remove global from options namespace (https://github.com/chartjs/Chart.js/issues/6684 https://github.com/chartjs/Chart.js/pull/6893)
  
  
  • Standardize on using degrees for angles (https://github.com/chartjs/Chart.js/pull/6936)
  
  
• Migrate docs from GitBook to Docusaurus (https://github.com/chartjs/Chart.js/pull/7295)
• Support tree shaking / individual module imports (https://github.com/chartjs/Chart.js/issues/7371)
• Leverage index / value concepts
  
  
  
  • Remove horizontalBar and make all charts capable of being horizontal (https://github.com/chartjs/Chart.js/pull/7144)
  
  

Proposed / Nice to Have Features

• Scale cleanups
  
  
  
  • Improve the scale interface & document how to use it
  
  
  • Investigate normalizing options.scales and option.scale keys for all chart types
  
  
• Performance Improvements
  
  
  
  • Support drawing charts without creating elements possibly as external chart type (https://github.com/chartjs/Chart.js/pull/6881)
  
  
  • When the tooltip and other hover actions are disabled, the chart should not be redrawn when hovering on it. This would make external custom html tooltips massively faster. Along with this, consider making the default tooltip be an external tooltip (https://github.com/chartjs/Chart.js/issues/7195#issuecomment-598996746)
  
  
  • Make sure the tooltip listener only applies to the chart area and not the whole canvas (https://github.com/leeoniya/uPlot/pull/277#issuecomment-663021669)
  
  
• Cleanup options (https://github.com/chartjs/Chart.js/issues/5233)
  
  
  
  • Remove overrides of _resolveDataElementOptions and _resolveDatasetElementOptions
  
  
  • Make _dataElementOptions an array in all controllers (i.e. line and radar).
  
  
  • Ensure user-specified options are applied after defaults. Delete _config and have just a single object holding resolved options
  
  
  • Make chart.options private and immutable (user should not directly edit, but should pass in new config to merge)
  
  
  • Cleanup interactions options (https://github.com/chartjs/Chart.js/issues/5861)
  
  
• Leverage index / value concepts
  
  
  
  • Bar / rectangle cleanup (https://github.com/chartjs/Chart.js/issues/6760)
  
  
• Make drawing clearer
  
  
  
  • Investigate making drawings sharper
  
  
• Consider renaming axis label to axis title to differentiate from the tick labels
• Improve log scale tick generation (https://github.com/chartjs/Chart.js/issues/7332)
• Bar chart
  
  
  
  • Allow specifying pixels between bars (e.g. 1 px space and fill the rest). Right now it can only be a percentage
  
  
• Ideas from @simonbrunel: Chart.js 3.pdf

Won't do

• Can we move hidden elements to plugin? (https://github.com/chartjs/Chart.js/pull/6255)
• Split out the time scale into it's own package
• Consider removing data from config so that we have datasets, labels, and options as first level properties. We agreed that data.datasets.data is confusing, but every chart would need to be updated if we changed this and all StackOverflow answers would be outdated

How can you help?

• Provide feedback on which issues you would like prioritized for v3
• Test out alpha & beta releases as they become available. The alpha release is quite stable though we have found a few issues. Thanks to the folks that reported them! Here's a list of known issues
• Volunteer time to help improve the project

[sebiniemann]

I would like to work on

• Change require to import

Should I do this within the current code base (may take a day for the whole projet, I could start during the upcomming weekend) aka master?

[etimberg]

@SebastianNiemann I think that's the best way to do it. We've already started merging breaking changes to master. If we need to do 2.9.x hotfixes we'll do that in a separate branch.

@benmccann @kurkle thoughts?

[benmccann]

Yes, go for it! I would love that :-)

[leeoniya]

Chart.js currently struggles with hover / live value display in large datasets. Might want to also look into this.

https://github.com/leeoniya/uPlot#performance

[benmccann]

Good suggestion! I filed https://github.com/chartjs/Chart.js/issues/6716 to discuss and track that issue

[kurkle]

Should we consider dropping IE support? It would make some new things available:
Proxy - for data change detection
Map - for array uniqueness (if we can't get rid of it). Its quite a lot faster really compared jsperfs test of it. (uPlot arrayUnique in ~25ms isntead of ~150ms)

Another thing worth exploring is ResizeObserver. That could be used, instead of current implementation, if supported.

[benmccann]

As much as I'd love to drop IE, I think there are still too many IE 11 users. The main website I'm working on right now has ~5% of traffic in IE. But it'd be great to use Proxy, Map, or ResizeObserver when they're available and fallback to the current methods for IE!

[etimberg]

I recall ResizeObserver not working entirely for div resizing last time I investigated a few years ago.

[leeoniya]

as another datapoint, our IE11 traffic for the past 2 weeks has been 2.65%, it was 5.62% for the same period last year. (usa, ecommerce, home remodeling industry).

at some point, as a lib/web author you gotta ask yourself whether maintaining IE11 compat further delays its inevitable death.

[benmccann]

For Map, you can just use it directly and have babel take care of polyfilling it.

[davidswinegar]

Hello - is there any movement towards enabling Chart.js to be used inside a web worker controlling an offscreencanvas? I've seen this issue: https://github.com/chartjs/Chart.js/issues/5355. If it's appropriate I'd be interested in taking on the necessary work to get it working. Let me know if there's anywhere I should get started! I'll probably be submitting some speculative PRs for this soon.

Context: a major project that we'll be taking on for https://github.com/cruise-automation/webviz in the near future is moving our Chart panel behind a web worker for performance reasons. We use Chart.js currently and love it, and we'd like to keep using it.

[etimberg]

@davidswinegar I haven't tried anything yet. However, I think the limitations would be similar to those for server-side rendering. I know that has been done a fair bit with Chart.js (example: https://github.com/shellyln/chart.js-node-ssr-example).

I think you would need to disable resizing since that needs access to the DOM. I also don't know if window.devicePixelRatio is available in a worker. One thing that would need dev work would be switching the canvas context on an existing chart. I think this would let you do:

1. Render initial chart offscreen
2. Copy the offscreen canvas image to the onscreen canvas
3. Point the chart instance to the onscreen canvas to allow interactivity

I am curious though, are you hitting performance bottlenecks in Chart.js itself? If so, you might like to try the latest code from master (will eventually release as v3) because @kurkle and @benmccann have been doing lots of performance improvements.

[davidswinegar]

@etimberg thanks for the info! I am hitting performance issues in Chart.js, though I'm not sure if it's because of the library itself or the fundamental cost of drawing on the canvas. I'll do some benchmarks on the code that's in master and see how it affects us.

[etimberg]

Sounds good. There are lots of breaking changes in master, and docs on those are https://www.chartjs.org/docs/master/getting-started/v3-migration.html

[benmccann]

Most of the work in 2.x is not related to drawing on the canvas. I think most of that work can be removed. A good chunk already has been. After that's done I don't know if web workers would still provide benefit?

If you use the version from master, which is much faster please see the updated performance documentation to make sure you set options that result in maximum performance. Most of the work has tested on improving line chart performance though many of those improvements help all charts generally. I'd be interested in any feedback you have if you try out what's in master (see the migration guide as there have been numerous changes) and how far off we are to meet your goals.

[davidswinegar]

I tried the version in master and followed the performance documentation and I definitely noticed an improvement! Thanks for the feedback., Our product requirements mean that this improvement won't be enough, though, and that we'll still have to put Chart.js behind a web worker. I'll take this to Slack to work through some approaches on the details.

For context, we're updating 5+ charts many times a second and attempting to play back data in real-time without dropping any data; our performance characteristics need to be closer to games than to analytics web applications. Regardless of how performant Chart.js is, passing data over a web-worker connection and drawing it from there is necessary for us to squeeze every cycle out of the browser - if we were writing our own performance optimized canvas library we'd still have to do this.

[leeoniya]

@davidswinegar if these are line charts, you can try uPlot to get an idea of what's possible in terms of performance.

[benmccann]

I'm aiming to get about another 10x increase in performance. I have a handful of pending PRs that are all geared towards improving performance. I'm happy discuss the web worker approach or any other perf ideas over Slack as you suggested

[leeoniya]

I'm aiming to get about another 10x increase in performance.

😮 that would be impressive! uPlot is currently at 40ms, Chart.js master is 305ms. 10x faster would be 25% faster than uPlot and i'm not really sure where i can shave a full 10ms!

[davidswinegar]

@leeoniya your numbers look impressive! I think that Chart.js is the choice for us because of support for panning & zooming, and more chart types, but I'll keep uPlot in mind.

[benmccann]

Re 10x: It depends which charts you're drawing, what dates you're comparing (e.g. master now is already significantly faster than master yesterday), etc. Plus, I said "about" so if I get 7-8x faster and round up I'll be pretty happy... ;-)

@davidswinegar depending how much you want to experiment you can try grabbing my two pending PRs. It gets Chart.js line charts from 550ms down to 100ms on the uPlot benchmark on my machine compared to 70ms for uPlot: https://github.com/chartjs/Chart.js/pull/6881#issuecomment-569968823. The "fastline" PR may be released as an external plugin rather than being merged into core, but should allow you to use other plugins with it still such as zoom/pan, etc. I'm curious what other chart types and scale types you use. I've been most focused on optimizing the time scale and line charts since that's what I use most myself

[stockiNail]

options.onClick is now limited to the chart area

I've seen that going to v3, the onClick function will be limited to chart area.
I've implemented specific functions in order to catch click events on axes and title because it could be helpful.

Do you think this new feature could be re-thought again?
Will this reduction of events scope apply to onHover as well?

[kurkle]

You can hook on the canvas click even directly to catch all clicks.
onHover might be changed too, it should only fire when an element is hovered.
Workaround will be similar, you can use mousemove event of the canvas.

[stockiNail]

You can hook on the canvas click even directly to catch all clicks.
onHover might be changed too, it should only fire when an element is hovered.
Workaround will be similar, you can use mousemove event of the canvas.

But in this case you have more listeners instead of one. It sounds redundant, in my opinion.
Anyway if you are going to this implementation, there is not other way, I guess.
What I can suggest here is if you are limiting the scope of click event to chart area, it could be better to do the same for onHover as well, to be consistent.
That means all events (defined at options level) have got chart area scope.

[mesqueeb]

I would love native support for treeshaking. Should be top of the priority list for me. 😉

eg. if I only use a single chart from chart.js in an app, I want it to not include any code for other charts I don't use. 💾

[Zilvinaskli]

better support for rounded corners would be nice

[benmccann]

Here's some examples of how you can get rounded corners today:

• https://github.com/jedtrow/Chart.js-Rounded-Bar-Charts
• https://stackoverflow.com/questions/31582555/how-to-put-rounded-corners-on-a-chart-js-bar-chart
• https://stackoverflow.com/questions/43254153/how-to-create-rounded-bars-for-bar-chart-js-v2

Though it looks like it might be a little harder for stacked charts: https://github.com/chartjs/Chart.js/issues/5413

[Zilvinaskli]

Here's some examples of how you can get rounded corners today:

• https://github.com/jedtrow/Chart.js-Rounded-Bar-Charts
• https://stackoverflow.com/questions/31582555/how-to-put-rounded-corners-on-a-chart-js-bar-chart
• https://stackoverflow.com/questions/43254153/how-to-create-rounded-bars-for-bar-chart-js-v2

Though it looks like it might be a little harder for stacked charts: #5413

that is the problem. I have been using these solutions so far and it works for stacked bars in some cases but I'm stuck now where I have to display negative stacked values.

[abdonrd]

Is there an estimated date for the v3? Thanks in advance!

[hc-codersatlas]

Any chance of pushing out a beta to npm so more people can start testing / integrating with existing systems / libraries?

[aried3r]

Hey! What do you think about publishing Chart.js in a scope on npm? That way it's easier to differentiate between official and unofficial packages and there's less chance of name clashes or package names that are unavailable.

There's a few packages on npm that are unofficial addons.
One example in our case would be chartjs-adapter-dayjs which we don't use, but have our own, private version of so we don't have to use moment.js. However the package name is taken, so unless the package (GitHub link is 404) would be donated, the name is already taken.

Other adapters with the same naming scheme are in the chartjs GitHub org.

For transition I'd release a last 2.x release with a post-install message that says that 3.x will be available in the @chartjs scope. That would also prevent people from accidentally updating to 3 if they don't use version constraints in their package.json and maybe use both 2.x and 3.x (alpha, beta, RC...) in case people want to slowly transition.

WDYT?

[joejordanbrown]

If you do decide to go down the scoped package, which I think is a good idea.

I just checked, and the scope @chartjs which @aried3r mentions above is already taken. I'm not sure if someone from Chart.js already has this?

I noticed @chart.js wasn't taken so I took it to prevent someone squatting it and then Chart.js not being able to find who has it.

If Chart.js would like that scope, let me know and I'll transfer it over to your team members.

[spaghettiismymiddlename]

This may have been asked before, but are there any thoughts or plans to support SVG?

[SuperPat45]

Chart.js V2 have two data properties:

new Chart(ctx, {
    data:  {
        datasets: [{
            data: [ 1 , 2, 3, 4
                ] } ] } } ) ;

This confused me many times at the beginning.
Any chance that one of the two "data" properties is renamed in Chart.js V3?

[cexbrayat]

v3.0.0-alpha was marked as latest on NPM, was it on purpose? https://www.npmjs.com/package/chart.js?activeTab=readme

[benmccann]

@spaghettiismymiddlename there are not currently any plans to support SVG

@SuperPat45 that's a good call out. My proposal would be to just remove the first data so that the config object takes labels and datasets directly rather than having an extra layer of nesting

@cexbrayat thanks for letting us know. This is the first time we're using our release script with a new major version. It looks like we'll need to fix it. We'll take a look!

[etimberg]

@cexbrayat thanks for the heads up. I've fixed the NPM tags so that v2.9.3 is latest and v3.0.0-alpha is next

[guykatz]

1. would love to have some kind out of the box drill down support
2. what are the roadmap dates for v3. I am starting a new project that will probably be out in half a year. should I already start with v3?
   thanks

[benmccann]

would love to have some kind out of the box drill down support

This is currently handled by plugins and will probably stay that way. E.g. see https://github.com/sgratzl/chartjs-plugin-hierarchical

what are the roadmap dates for v3. I am starting a new project that will probably be out in half a year. should I already start with v3?

There are no roadmap dates currently. Some considerations that may help you decide:

• I hope that v3 should generally be pretty stable since we have a decent test suite. Our focus is currently on v3, so any bugs that are reported will generally only be fixed for v3 and not for v2.
• We have probably made the majority of breaking changes that will be made, but there will definitely be more between now and a final version of v3.
• Most plugins won't support v3 for awhile.

[andig]

Hope this is not considered spam. After revisiting 2.9.3 after some time now I'm still confused at how difficult it seems to be to generate proper-looking time series charts for non-equidistant data points. I'd expect a simple mechanism for controlling minor/major tick generation for such charts to avoid having to pass in custom labels.

Update I have the same observation for any linear scale. Tick generation is one are where the outdated Flot excelled. If there's any interest for discussion this I'd be happy to provide examples/ pain points.

[lekoaf]

API Documentation generated and verified by TypeScript

What does that mean exactly? Because I don't see any type definitions on the alpha branch.

Regards,
Martin, one of the maintainers of @types/chart.js.

[benmccann]

It means we generated TypeDocs: https://www.chartjs.org/docs/next/typedoc/. Perhaps we should change "TypeScript" to "TypeDoc" in that sentence to be clearer

[vladshcherbin]

After testing v3 alpha version top priority is tree shaking for me. Simply adding one line chart increases bundle size from 6kb to 60kb with gzip 😱

As for user experience, data.datasets[0].data is really frustrating, data word in docs is very confusing. Usingdatasets[0].data seems more logical and understandable.

Everything else worked really well 👍

[ktrzos]

Hello! I've got one question. Any chance of publishing v2 without Moment as dependency?

[benmccann]

You can use v2 without the Moment dependency already today: https://www.chartjs.org/docs/latest/getting-started/integration.html#bundlers-webpack-rollup-etc

[mesqueeb]

@benmccann on a sidenote, I'd hope (and a lot seem to agree) that you could move Support tree shaking / individual module imports up to the "committed features" section. 😍

[benmccann]

We would love to have that feature. If anyone would like to volunteer, I'd be happy to discuss what is needed. I can't promise anyone will get to it otherwise since our time is limited, but I do agree it'd be a big improvement

[etimberg]

I've played around with the docusaurus build. I don't have any big complaints. @kurkle have you had a chance to look yet?

[tsung-wei-huang]

Is v3 going to include timeline chart? I still didn't see this in the list :(

[benmccann]

There's a plugin that someone created for a timeline chart: https://github.com/fanthos/chartjs-chart-timeline (Demo: https://jsfiddle.net/fanthos/8vrme4bt/)

v3 doesn't included any new chart types in the core library. Our focus has been on changes to the core library to make it faster, more configurable, with fewer bugs and edge cases. If there are any changes we can make to the core library to better support plugins like the above then we're happy to consider those changes

[Bradley-H]

Will Charts have a US / World map type of chart?

[benmccann]

No, there are no new chart types as explained in my comment just above yours

[benmccann]

@Bradley-H I just remembered there's already a plugin for maps: https://github.com/sgratzl/chartjs-chart-geo

[jasonatball]

I did a little performance testing on my Windows 10 laptop with a i7-8650U @ 1.9GHz and 16GB Ram. I preload data.datasets with 10 datasets containing time stamps and incrementing data points. I then console time around the call to new Chart(). I got the following results:

10,000 pts each (100,000 total) takes 1.5-2s, Chrome uses 520MB
20,000 pts each (200,000 total) takes 3-4s, Chrome uses 1GB
40,000 pts each (400,000 total) takes 7-8s, Chrome uses 1.8GB

So it looks like it's pretty much scaling linearly with the points. I use the following options to increase performance:

  options: {
    spanGaps: true, // enable for all datasets
    animation: false,
    scales: {
      x: {
        type: 'time',
        display: true
      }
    },
    elements: {
      line: {
        tension: 0, // disables bezier curves
        fill: false,
        stepped: false,
        borderDash: []
      },
      point: {
        radius: 0 // default to disabled in all datasets
      }
    }
  }

Since I'm trying to use it for real-time graphing I need as much performance as I can get because 1Hz data for 8hrs is 60 * 60 * 8 = 28,800. If I have 10 items on a graph that would be 280,800 pts. Are there other tricks I can use for performance or other new optimizations in v3.0?

[benmccann]

There are performance docs here: https://www.chartjs.org/docs/next/general/performance

You might also try https://github.com/chartjs/Chart.js/pull/6881 if performance is really important

However, I would also suggest you probably don't need that many points. Consider, for example, showing one data point per minute instead of one data point per second. If you have more than one point per pixel, I'm not sure how you would get benefit from additional data points after that

[jasonatball]

Thanks Ben. I think I've implemented most of the performance options. The primary reason we graph so many points is the ability to zoom in and out on the graph. These are real-time graphs so decimating server side and then re-requesting data on zoom doesn't seem possible since the user could then immediately zoom out and resume. Otherwise v3.0.0-alpha worked great!

[sgratzl]

FYI I created for the following plugins alpha versions targeting v3:

• maps: https://github.com/sgratzl/chartjs-chart-geo
• boxplots: https://github.com/sgratzl/chartjs-chart-boxplot
• pcp: https://github.com/sgratzl/chartjs-chart-pcp
• graphs: https://github.com/sgratzl/chartjs-chart-graph
• error bars: https://github.com/sgratzl/chartjs-chart-error-bars
• hierarchical category scale: https://github.com/sgratzl/chartjs-plugin-hierarchical

[sgratzl]

Will Charts have a US / World map type of chart?

take a look at https://github.com/sgratzl/chartjs-chart-geo

[sebiniemann]

Following the idea behind https://github.com/chartjs/Chart.js/issues/5939 (avoiding misleading charts per default) I would like to suggest to set cubicInterpolationMode to monotone as default.

[benmccann]

Wouldn't turning off interpolation all together be even better from that perspective? (i.e. lineTension: 0)

[etimberg]

I am ok with lineTension off by default. It was enabled in v2 because it was a default in v1

[bairog]

Hello,
According to docs browser support is the same for Chart.js V3 alpha (Chrome 50+, Firefox 45+, Internet Explorer 11, Edge 14+, Safari 9+). Is that subject to change or it is final plan for Chart.js V3 release?
Thank you.

[benmccann]

We are still supporting those browsers

[etimberg]

A 2nd alpha version, v3.0.0-alpha.2 has been released. Release notes are available at https://github.com/chartjs/Chart.js/releases/tag/v3.0.0-alpha.2

There are a number of breaking changes compared to v3.0.0-alpha to support tree shaking.

[sgratzl]

there are also new alpha versions targeting v3-alpha.2:

• maps: https://github.com/sgratzl/chartjs-chart-geo
• boxplots: https://github.com/sgratzl/chartjs-chart-boxplot
• parallel coordinate plots: https://github.com/sgratzl/chartjs-chart-pcp
• graphs: https://github.com/sgratzl/chartjs-chart-graph
• error bars: https://github.com/sgratzl/chartjs-chart-error-bars
• hierarchical category scale: https://github.com/sgratzl/chartjs-plugin-hierarchical
• venn diagrams: https://github.com/upsetjs/chartjs-chart-venn

[jonrimmer]

Are there any type definitions for the alpha? I imagine most consumers of the library are using TypeScript, and it's difficult to test without them.

[etimberg]

@jonrimmer unfortunately we haven't had a chance to try and write definitions yet. Personally, I've used @types/chart.js in one of my projects and I know for sure that the types could be improved.

I'm not sure what the best way to start developing types would be. @benmccann @kurkle any thoughts?

[sgratzl]

I start writing typings for https://github.com/sgratzl/chartjs-esm-facade/blob/master/src/index.d.ts. However, atm they are focusing on the plugin developer side, so more on typing scales, controllers, ... and less about the config.

One thing I haven't figured out yet is how to type the configuration such that:

• it is extensible (e.g. adding a new controller configuration type)
• the options just list the valid options of the controller

[jonrimmer]

Thanks @sgratzl those look very useful.

I guess a key question is, is there a willingness to manage type definitions directly within the Chart.js project itself? I.e. use @types/chart.js and @sgratzl's definitions as the basis for definitions shipped with the main package and evolved in tandem with changes to the library's implementation?

I don't know if there's any thought to eventually using TS within the codebase itself, but this would seem to be a useful first step towards that. If there isn't, it would still make the developer story of using Chart.js with TypeScript easier.

[kurkle]

I think it would be best to include the definitions main package, because @types/chart or any other external types will always be somewhat outdated or for a specific version.

[sgratzl]

happy to help integrating the definitions directly in chart.js, since I'm a huge TypeScript fan

[etimberg]

I would be OK with types included with the main package. A lot of my new code these days in Typescript

[xr0master]

Wow. After alpha, version 2 looks much better. Awesome job!
In alpha.2 tooltips callbacks have been heavily modified. Is this planned? Is it safe to get labels from the chart?

// title: (items) => {}
const {dataIndex, chart} = items[0];
chart.data.labels?.[dataIndex]

[kurkle]

@xr0master the item contains label also, that is safe.

[xr0master]

@kurkle Right! But the label is formatted. So I need to parse them in title which is not very effective. Can I cancel formatting?

P.S. I use a time scale, and my type of labels is Date.
P.P.S. I'm using parsing: false for scale, but it doesn't cancel the tooltip formatting. Perhaps I did not fully understand the ability of this flag.

[benmccann]

You can use the dataPoint field to get the unformatted data. Here's an example on the timeseries scale: https://www.chartjs.org/samples/next/scales/financial.html. If you still have further question about this it's probably better to ask over Slack or file a new issue, so as not to take this ticket off-topic

[christopherlam]

Just a small note from a GnuCash committer -- chartjs is a nice backend for charts. And https://github.com/kurkle/chartjs-chart-sankey from kurkle makes for a nice cash-flow chart for a future release: https://github.com/Gnucash/gnucash/pull/759. Embedding chartjs and webkit is a challenge because webkit has dropped support for win32, so we have to use old javascript only. As a result charts in gnucash on win32 and macOS are not responsive. So, while modernizing javascript is fine; some fallback methods would be great too!

[benmccann]

@christopherlam you can use resize-observer-polyfill in your project to address that. We include it in the UMD build. However, in the npm build we omit it to give users the option as to whether they want to include it or not depending on the set of browsers they support

[Cristy94]

Hey guys, great work! 🎉

I am really excited for the v3 release and the title of this issue is "State of Chart.js & V3.0", but I still don't know what's the current state, how stable it is and how far from production-ready it is.

In the post it says The alpha release is quite stable. Is it safe to assume there would be no big API changes for v3? Do you think it's a good idea to use it in production for basic time series line charts?

[etimberg]

@Cristy94 I don't think there will be major breaking changes after the alpha.2 release, but I can't guarantee that. Personally, I am using alpha.2 in production and I have not run into problems.

[Cristy94]

@etimberg Thank you! I will soon switch to v3, as I wanted to implement some custom rendering and it's probably better to do it in v3 instead of trying to port it.

Are there any hosted examples (demo page) of how v3 chartjs looks like? I haven't seen any interactive demos or images in the docs.

[etimberg]

The latest v3 sample files are hosted at https://www.chartjs.org/samples/master/

[Cristy94]

Thanks, I also noticed some examples in the Docs, under the Configuration section: https://www.chartjs.org/docs/next/configuration/animations

EDIT: Oh, the examples are in "Chart types": https://www.chartjs.org/docs/next/charts/line

[xr0master]

@Cristy94 I'm using alfa.2 for production too. I think the best docs for v3 at the moment is migration doc: https://www.chartjs.org/docs/next/getting-started/v3-migration

[darkship]

With the alpha2, I was able to reproduce about 20 of my company's charts. Bars, pies and lines with different aspects of legends, title, tooltips, stacked, etc...
One of the chart had so many lines and points that nearly every pixel had a tooltip but it was still smooth.

I had some issue with the "pie" type where having the scaling configuration from "line" made it explode.

Can I already consider the API as stable? I didn't see many changes on the API in the last months (due to COVID19 effect maybe?)

[xr0master]

A bit offtopic and advertising. I wrote a React wrapper for chat.js version 3. I use it for production.
https://www.npmjs.com/package/chartjs-react
Maybe someone will come in handy.

P.S. Forgive me if this is not correct, I am not very familiar with the rules in open source projects.

@darkship the tooltips callbacks have been heavily modified. IMO

[Eonasdan]

I'm looking forward to being able to use chart.js v3 in my angular project. Hopefully ng2-charts will update and I'll be free of the new angular 10 warnings about commonjs/amd libs.

I'd like to throw my 2 cents about IE11 support and recommend that you drop support for it. Bootstrap 5 will no longer support among the many many sites that are dropping support for it. If people still need IE11 they should stay on chart v2 or they can use polyfills. Much like the BS 5 - IE11 discussion I agree that library's should no longer held back by IE11 and that forward momentum is only possible by dropping support for it.

[sakulstra]

Is there any date-adapter which is already ported to work with the beta-0?
Just tried upgrading a project of mine to test-run the beta, but it seems like the new import/register structure broke parts of the plugin ecosystem i'm relying on.

https://github.com/chartjs/chartjs-adapter-luxon/pull/12#issuecomment-684995403

[kurkle]

chartjs-adapter-date-fns@next

[xr0master]

Guys, please do not consider me arrogant, but there are plans for the version of Beta.2?
I'm really looking forward to it.

[etimberg]

@xr0master I was waiting until #7806 got in before cutting a new release.

[literakl]

7806 was merged already in september.

[etimberg]

@literakl that released in v3.0.0-beta.2.

[godenji]

Question about tree shaking in v3.

Given the following:

Chart.js 3.0.0-beta.7
Angular 10.2.0
TypeScript 3.9.4
NodeJS v12.18.2

and a basic chart config:

import { Chart, Title } from `chart.js`

Chart.register(Title);

const chart = new Chart(ctx, {
    type: 'line',
    // data: ...
    options: {
        plugins: {
            title: { display: true, text: 'Chart Title' }
        },
        scales: { y: { stacked: false } }
    }
})

source-map-explorer shows Chart.js weighing in at 148KB, just 20KB less than Chart.js.min -- is this to be expected, or should users be seeing a (much) greater reduction in bundle size given the above setup?