Premium Analytics: adaptive sizing for the Posting activity heatmap

[louwie17]

Proposed changes

The Posting activity widget rendered its calendar heatmap in the chart's fixed-square compact mode at a fixed size, so it never adapted to the tile — tiny in tall tiles, and a full year overflowed into a horizontal scroll in narrow ones. It also only spanned the weeks that happened to contain posts. This makes the heatmap adapt to its tile and always show a full range.

Sizing (pure geometry + widget policy)

• New layout.ts: computeCalendarHeatmapLayout (expanded cell size, column count, exact rectangle) and fitCalendarHeatmapColumns (how many fixed cells fit a width). Dependency-free (no React/charts imports) so it can later be lifted into @automattic/charts.
• The widget measures the tile (useElementSize on the parent div) and picks the mode from its height:
  • Expanded (taller tiles): scaled 61:40 cells with in-cell numbers, sized to the computed rectangle via HeatmapChartUnresponsive width/height — so the chart's minmax(0,1fr) tracks produce the exact cells (no wrapper div, no double measurement). I borrowed the 61/40 from Eders demo, but we can adjust this.
  • Compact (shorter tiles): the chart's own fixed-size squares (compact prop) — the widget doesn't scale it, only trims the data to the columns that fit the width, so the max-content grid never scrolls.
• Both paths trim to the most-recent weeks when the tile can't fit them all. Width isn't part of the mode choice — a tall-narrow tile goes expanded and the 4-column-minimum shrink keeps cells fitting (minColumns is the knob to show more weeks there).

Data

• Floor the stats/streak fetch to at least a year ending on the picker's end date (resolveStreakRange) — a calendar heatmap needs a span of weeks, not a 7-day slice.
• Densify the sparse { 'yyyy-MM-dd': count } response (only days with posts) to the full window, missing days → null (buildStreakSeries). Without this, buildCalendarHeatmapData derives its range from the returned data's min/max, so posts clustered in a narrow window would still collapse to a few columns even with the year-long fetch.

Toolkit

• Expose HeatmapChartUnresponsive and useElementSize through the widgets-toolkit passthrough (widgets must not import @automattic/charts directly). No charts-package change.

No changes to @automattic/charts are needed — expanded sizing reuses the existing HeatmapChartUnresponsive width/height, and compact reuses the existing compact prop.

Closes: WOOA7S-1693

scalable-heatmap.mp4

Related product discussion/links

• WOOA7S-1693: Posting activity heat map only shows a single week

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

No — same stats/streak endpoint; only the requested date window is widened.

Testing instructions

• jetpack build --deps packages/premium-analytics (or pnpm run build), then run Storybook for js-packages/storybook.
• Open Packages / Premium Analytics / Widgets / PostingActivity → WidgetDashboardWithWidget and drive the size controls (widgetWidth, widgetHeight, rowHeight, dashboardWidth):
  • Short/narrow tiles — compact fixed squares, columns trim to the most-recent weeks, no horizontal scroll.
  • Tall tiles — expanded 61:40 cells with per-day numbers, sized to the tile.
  • The heatmap always spans a full year of week columns regardless of the date-picker range.
• Open the Analytics dashboard and add the "posting activity" widget, increase/decrease the size, it should scale accordingly.
• Unit tests: pnpm --filter automattic/jetpack-premium-analytics test -- widgets/posting-activity (31 tests across the layout geometry, column fit, the ≥365-day range floor, and the streak-series densification).

🤖 Generated with Claude Code

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report

[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!

[louwie17]

Going to go ahead and merge this, given the changes are quite self contained. We can iterate :)