Charts: Let a line chart show a period with no data

[adamwoodnz]

Fixes CHARTS-284

Why

A line chart can now show a period that has no data. Before, one null value made the whole chart print "Invalid data". Now the line breaks at that period and starts at the first real reading, its tooltip says "No data", and the start and end markers sit on real readings. This is the line chart half of #52522 (merged), and Premium Analytics needs both before it can stop turning a missing subscriber count into zero (WOOA7S-2181, #52523), because its Subscriber summary switches between bar and line.

Proposed changes

• One rule for a drawable reading. A new private readings.ts holds isReading, isInvalidReading and formatReading. The bar and area charts move onto it with no change in behavior; the area chart still rejects null, because its stack layout cannot take a gap.
• The line chart accepts null. validateData lets it through and still rejects undefined and NaN, and its two error strings are now translated. No accessor change is needed: d3's linear scale maps null to undefined, which visx's AreaSeries defined check already rejects, so the line and its fill break on their own.
• The tooltip says "No data" instead of 0, and sorts missing readings last. The exported TooltipDatum.value widens to number | null to match.
• Pointer events reach a bucket with no reading. visx's nearest search adds the y distance, which is NaN for a null reading, so a pointer over a bucket where no series had one fired nothing: a drag-to-zoom could not start there, and onPointerDown / onPointerUp never reached a drill-through. The chart now finds the nearest datum along x itself, preferring a series with a reading, as the bar chart's BandTooltip does.
• The start and end glyphs sit on the first and last real reading. Before, a leading or trailing null made them disappear.
• A window with no readings keeps a y axis. When no visible series has a reading, the axis falls back to 0 to 1. A caller's own domain, or an axis pinned by rescaleYOnVisibilityChange={ false }, still takes priority.
• A flat line's value axis starts at zero. Null buckets make a flat series common: a steady subscriber count after the months before launch collapsed the domain to one value, and d3 drew the line halfway up the plot while the same data as bars reached the top. When every visible reading is equal, a linear axis now runs from 0 to that value, or 0 to 1 when the value is 0. A log scale is unchanged.
• A BucketsWithNoData story, docs, and changelog entries.

Screenshots

The BucketsWithNoData story, matching the bar chart's: January to March have no reading, April is a real zero, and May to July climb.

The line starts at April, at 0, with the start glyph on its first reading and nothing before it

A month with no reading: the tooltip says "No data", not 0

On a month with no reading the tooltip sits at the top of the plot, because there is no point to anchor it to. It stays over the right month and reads correctly.

A real zero: April's tooltip reads 0, anchored on its point

Related product discussion/links

• CHARTS-284. Follows CHARTS-281 (Charts: Let a bar chart show a period with no data #52522). Unblocks WOOA7S-2181 (Premium Analytics: Show months with no subscriber data as a gap #52523).
• Not changed here: CHARTS-282 (the value axis does not start at zero for data that varies, visible in the story; only the flat case is fixed here) and CHARTS-283 (repeated tick labels on a small whole-number range).

Does this pull request change what data or activity we track or use?

No.

Testing instructions

In Storybook, open JS Packages / Charts Library / Charts / Line Chart / Buckets With No Data.

• The x axis runs January to July; the line starts at April, at 0.
• Turn on withStartGlyphs and withEndGlyphs: the glyphs sit on April and July.
• Click the chart and press ArrowRight: January reads No data, not 0. The fourth press reaches April, which reads 0.
• Turn on zoomable and drag from January to May: the chart zooms. Before this change, a drag starting on January did nothing.
• Error States still shows "Invalid data" for its invalid series.
• The Area Chart stories are unchanged, including its error state for a null value.

Verified:

• pnpm run test in projects/js-packages/charts: 103 suites, 1684 tests passing.
• The flat axis in wp-admin, through Premium Analytics: Show months with no subscriber data as a gap #52523: the Subscriber summary's line mode now draws a flat count at the top of a 0 to 1 axis, level with its bars.
• pnpm run typecheck: clean. ESLint: clean on every changed file.
• Every step above except the area chart, in a Playwright browser against the dev server. The screenshots are from that run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GZqouXJVXUJX4ywMC8krzp

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the charts-284-line-chart-cannot-render-a-bucket-with-no-data branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack charts-284-line-chart-cannot-render-a-bucket-with-no-data

bin/jetpack-downloader test jetpack-mu-wpcom-plugin charts-284-line-chart-cannot-render-a-bucket-with-no-data

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

Coverage changed in 3 files.

File	Coverage	Δ%	Δ Uncovered
projects/js-packages/charts/src/charts/line-chart/private/line-chart-glyph.tsx	16/17 (94.12%)	-5.88%	1 ❤️‍🩹
projects/js-packages/charts/src/charts/bar-chart/bar-chart.tsx	153/157 (97.45%)	-0.03%	0 💚
projects/js-packages/charts/src/charts/line-chart/line-chart.tsx	164/166 (98.80%)	0.20%	0 💚

2 files are newly checked for coverage.

File	Coverage
projects/js-packages/charts/src/charts/line-chart/private/nearest-pointer-events.tsx	41/45 (91.11%) 💚
projects/js-packages/charts/src/charts/private/readings.ts	6/6 (100.00%) 💚

Full summary · PHP report · JS report

[adamwoodnz]

Review cycle summary

Status: clean. Ready for human review, after #52522.

Round reviewer: Codex, per this repo's preset. Two rounds.

• Round 1:
  • P2, a log-scale y axis got [ 0, 1 ] with no readings. Fixed (3ca9fe7), with a test.
  • P2, a single-value hidden series with rescaleYOnVisibilityChange={ false }. Declined: stableYDomain already refuses a degenerate range, and padding around one value would change flat-series rendering for every caller that turns rescaling off.
  • P3, the story's hidden control. Declined, and checked against Storybook: table.disable already removes it from the Controls panel.
• Round 2: the same single-value case again, narrowed to "prefer a padded domain". Still declined, for the same reason.

Final review: the Claude app, one round. No blocking issues, and it agreed with both declines.

• Fixed (c3c2884):
  • isInvalidReading now takes the chart value type instead of unknown.
  • The fallback comment no longer says "window".
  • A docs bullet that did not parse.
• Left as is, with reasons in the thread:
  • The glyph's y check, which narrows visx's scale return type to number.
  • The public TooltipDatum, which custom tooltips never receive. They get DataPointDate, whose value is already number | null.

CI: 89 passing, no failures. Code coverage requirement stays pending: this PR's base is the CHARTS-281 feature branch, which has no coverage data. The coverage bot says that is expected, and it resolves once #52522 merges and this PR is retargeted to trunk.

Inline review threads: none were opened.

Human reviewer comments: none yet.

Merge order: #52522 (bar chart), then this PR, then #52523 (Premium Analytics, WOOA7S-2181).

[chihsuan]

Thanks for closing the line chart half of this! @adamwoodnz Tested well.

Three inline notes. Not blocking this PR, but I'd love the pointer one settled before #52523.

[adamwoodnz]

Codex review

The replacement pointer selection changes existing numeric callback behavior and mishandles numeric values that cannot be placed on log scales. It also regresses pointer-move complexity from logarithmic to linear in all plotted points.

Full review comments:

• [P1] Match visx's numeric nearest-datum ordering — projects/js-packages/charts/src/charts/line-chart/private/nearest-pointer-events.tsx:48-48
  For all-numeric series with different x positions, this changes the callback result from the pre-change XYChart behavior: visx compares sqrt(distanceX + distanceY), whereas Math.hypot compares Euclidean distance. For example, candidates at (100, 0) and (60, 60) select the first in visx but the second here, so onPointer* (and chained zoom handlers) can disagree with the tooltip's still-visx selection. Use visx's existing distance comparison for finite candidates and add a regression test with offset series dates.

• [P2] Avoid treating log-invalid numeric points as null buckets — projects/js-packages/charts/src/charts/line-chart/private/nearest-pointer-events.tsx:44-44
  A numeric zero or negative datum on a log y-scale with a positive domain produces a non-finite scaled y, so this filter leaves no withReading candidates and the x-only fallback reports that invisible numeric datum. Before this change, visx emitted no pointer callback because its nearest distance was non-finite; now a blank log plot can invoke consumer handlers and start zooming as though it had selected a point. Track whether a candidate's raw value is actually null, and use the x-only fallback only when every candidate is a missing bucket.

• [P2] Use binary search for per-series pointer lookup — projects/js-packages/charts/src/charts/line-chart/private/nearest-pointer-events.tsx:27-27
  Every pointer move now evaluates and scales every datum in every visible series. The replaced visx lookup uses scale.invert() plus a bisector and is O(log n) per series, while this is O(total points), including for non-zoomable charts because useXZoom always supplies handlers. On charts with long historical series this runs at pointer-move frequency and can make hover/drag noticeably sluggish. Preserve the prior bisected lookup (or implement an equivalent binary search) and only do constant work for the nearest candidate.

[adamwoodnz]

Responses to the Codex review of the pointer change:

P1, match visx's numeric ordering: not applied. The tooltip does not use sqrt(distanceX + distanceY). visx's TooltipProvider compares Math.sqrt(distanceX ** 2 + distanceY ** 2), the same Euclidean distance as Math.hypot here. The un-squared form in useEventHandlers is an operator-precedence bug (distanceX ?? Infinity ** 2 squares only the fallback). So copying it would make the callbacks disagree with the tooltip, which is the problem the finding describes. The difference only shows for series with offset dates, and the new behavior is the one that matches what the user sees highlighted. I added a comment at the metric to say so.

P2, log-invalid readings: fixed in 25ca546. Only a genuine null bucket takes the no-reading fallback now. A number the scale cannot place is dropped, as visx dropped it, so a blank log plot fires no callback. A test covers 0 on a [1, 100] log domain, and it fails against the previous commit.

P2, binary search: fixed in 25ca546. useChartDataTransform sorts each series by date, so the lookup now bisects with xScale.invert like visx's findNearestDatumSingleDimension, and checks only the two neighbors. It falls back to a scan only for a scale without invert. A test covers a 60-point series.

Charts tests: 1684 passing. Typecheck and ESLint: clean. In Storybook, a zoom drag from January and one from May both zoom, and hover tooltips still read No data, 0 and 58 across the line.

[adamwoodnz]

Codex review

P1 — AGREE / ACCEPTED-DECLINE: AreaSeries sends per-series nearest results to TooltipProvider, whose Euclidean calculation matches Math.hypot; the malformed POINTER_EVENTS_NEAREST branch in useEventHandlers does not determine this tooltip ordering.
P2 log-invalid — PARTIALLY AGREE / STILL OPEN: the callback now drops an unplaceable candidate, but TooltipProvider still selects it at infinite distance.
P2 binary search — DISAGREE / STILL OPEN: zoomed domains, out-of-domain points, and sorted ties work, but the claimed sorted-data invariant fails for optional or missing dates.

Full review comments:

• [P2] Keep log-invalid readings out of visx tooltip selection — projects/js-packages/charts/src/charts/line-chart/private/nearest-pointer-events.tsx:53-55
  When the nearest datum is 0 or negative on a log y-scale, this filter makes the callback skip it, but each AreaSeries still emits its findNearestDatumX result to TooltipProvider; that provider converts its NaN y-distance to Infinity and stores it (node_modules/@visx/xychart/esm/utils/findNearestDatumX.js:18-23, node_modules/@visx/xychart/esm/providers/TooltipProvider.js:40-66). A one-series chart therefore displays a 0 tooltip while its pointer handler receives nothing, and null plus unplaceable series resolve differently on infinite-distance ties. Filter these readings from the tooltip path too, or make both paths use the same selection policy. Verdict: STILL OPEN.

• [P2] Fall back to scanning series with missing x values — projects/js-packages/charts/src/charts/line-chart/private/nearest-pointer-events.tsx:27-32
  For a newly valid null-bucket series containing an absent date, the transform does not establish ascending x order: its comparator returns 0 whenever either date is missing (use-chart-data-transform.ts:53-55), while DataPointDate.date is optional. For [Jan 2 null, undated null, Jan 1 null], a pointer at Jan 1 bisects to index 0 and reports Jan 2, whereas the prior scan selected Jan 1. Only bisect finite monotonic x values; otherwise skip invalid x values and scan. Verdict: STILL OPEN.

[adamwoodnz]

Responses to the Codex follow-up:

P1: agreed, closed.

Log-invalid readings in the tooltip: declining for this PR. The tooltip path is visx's own (AreaSeries → TooltipProvider), and this PR does not change it. On trunk a 0 on a log scale already shows 0 in the tooltip while the chart-level pointer callbacks fire nothing. 25ca546 restores that trunk behavior for the callbacks after the earlier commit changed it. How a log scale should treat a reading it cannot place is a separate question from null buckets.

Undated points and the bisect: declining for this PR. visx's findNearestDatumSingleDimension, which trunk used, bisects the same data with the same ordering assumption, so trunk picks the same datum for [Jan 2, <no date>, Jan 1]. A point with no date or dateString has no position on a time axis, so that input is already broken. The fix belongs in validateData, which only rejects an invalid date, not a missing one. That is a separate change.