Two fixes, both about a message the library gives you when you are trying to find out what is going on.
api.drawn() answers who put a mark on this chart, and it credited a note the VIEWER drew to the page that embedded the chart. That is the one case the owner field was added for.
And the error you get for an unregistered chart type ended by advising the full bundle, which is not an escape hatch for a type that is opt-in: following it fetches a megabyte and raises the same error again.
| gzip | |
|---|---|
| 7.6.0 default bundle | 271,534 B |
| 7.6.1 default bundle | 271,606 B |
Both are dist/apexcharts.min.js gzipped at the default level, which is the figure npm run build prints.
Upgrading is npm install apexcharts@7.6.1.
🐛 Fixes
Report a note the viewer drew as ink, not as the caller's own
Ink strokes ARE annotations, so they reach api.drawn() through the annotation contributor, which defaults every row to core: the caller put it in their config. That reported a note somebody drew on the chart as the caller's own, so a readout answering "which of this is mine" answered it wrongly, which is worse than declining to answer.
The two places this layer CREATES an annotation now set owner, and only those two. Authored by, not draggable by: _attach() walks the caller's annotations to make them draggable and stamps an apexcharts-ink-* id on any that lack one, so the id is not evidence of authorship and attributing by prefix match would take authorship away from the person who wrote it. The second test pins that by handing a caller annotation an ink-shaped id literally and asserting it still reports core.
Plan 26 P5: the phasing table already recorded this as the visible consequence of the phase being open.
The full entry does not carry ink, so the spec imports the feature; the tests would otherwise have asserted against a chart with no ink at all.
Stop telling opt-in types to load the full bundle
getChartClass's error ends with "or load the full apexcharts.js instead", which had been true of every chart type until icicle. An opt-in type ships only as its own sub-entry and the default bundle carries no class for it, so a reader who follows that advice fetches a megabyte and meets this same error again. It is the worst shape of wrong advice: the rest of the message is good enough to be trusted first.
RESERVED_TYPES is already exactly the set in question, reserved BECAUSE the default bundle does not carry the class, so the branch costs an import and no new list to maintain.
Also drops "after apexcharts.core.js" from the script-tag line. A sub-entry registers onto whichever shared class is present, so it works after the full bundle too, which is what this repo's own samples do. Naming core made the thing our samples do look unsupported.
Four tests in tests/unit/chart-factory-errors.spec.js; two of them fail on main. The file deliberately does not import the icicle entry, since that would register the type and make the branch unreachable. Full unit suite green: 156 files, 3599 passed.