Premium Analytics: measure the date presets instead of guessing a breakpoint

[retrofox]

Fixes WOOA7S-1816
Part of WOOA7S-1793

What?

The date range presets now shorten their labels before collapsing into a select, and both switches are decided by measuring the active language's own labels rather than comparing the container against a fixed width.

Implements WOOA7S-1816, on the measurements from WOOA7S-1817. Design: Eder's p1785208001025929-slack-C06FSDTSN82, "Responsive format".

Also included, because they surfaced while measuring:

• The custom-range trigger truncates a long label instead of wrapping it.
• DateFiltersPanel measures itself, so containerElement is gone from 12 call sites.

Why?

The panel collapsed its presets into a select below a fixed 600px. That number was picked against English, and English is the shortest case. Measured through CoreText at the pill's real type settings, across the 15 locales that translate all four preset labels:

locale	preset group	vs English
ru	572px	1.49x
nl	526px	1.37x
cs	525px	1.36x
de	478px	1.24x
en	385px	baseline
ko	304px	0.79x

German is not the worst case, it is seventh. CJK is narrower than English. Russian is the outlier, and the whole row needs 694px there against 470px in English.

Two consequences. A fixed threshold is wrong for almost every language, by up to 225px. And collapsing straight to a select was throwing away a click for no reason: abbreviated labels fit in a fraction of the room, so the select only becomes necessary far below where it used to fire.

Counting characters would not have found this. Последние 7 дней is 1.45x English by character count but 1.69x by rendered width.

How?

PresetLabelMode (full / abbreviated / select) replaces the isCompact boolean. isCompact survives only as labelMode === 'select', for the popover and the compact CSS.

PresetRowProbe renders the preset row twice off-screen, once per label form, inert and at max-content, and reports both natural widths. Measured in the DOM rather than computed, because the width depends on the font resolved for the locale's script, the button padding tokens, and the group's borders — reproducing that in JS would be a second implementation of the same layout, free to drift.

It renders both forms unconditionally. This is the load-bearing detail: measuring the live row oscillates, since shortening the labels shrinks it, the full labels then look like they fit, and back again.

resolvePresetLabelMode( availableWidth, rowWidths ) is a pure function picking the longest form that fits. There is no threshold constant left. WIDE_CALENDAR_CONTAINER_THRESHOLD stays one on purpose: the calendar's content is two month grids, whose width does not follow the locale's strings.

The abbreviations are _x() strings with translator context, not truncations. Last 24H and 7D are English initials; without context a translator leaves them in English and a Russian reader sees 7D.

flex-wrap: nowrap on the rolling group, now that shortening happens before overflow. That also retires an artifact: the group's hairline dividers are drawn with > * + *, which knows nothing about row breaks, so a wrapped row's first pill painted a border on top of the group's own frame. Scoped to that group rather than the shared mixin, since the year surface has no abbreviated form to fall back on yet.

Self-measurement

Every one of the ten page consumers wrapped the panel in a div and handed it back as containerElement, so the value was always the panel's own width. The panel now observes its own root. The two ReportParamsField copies also lose a document.querySelector( '.next-admin-layout__surface' ) workaround that existed only to feed the prop, and whose upstream fix (WOOA7S-1008) was cancelled.

Net effect on the call sites: 137 lines removed, 32 added.

Testing

Storybook: cd projects/js-packages/storybook && pnpm run storybook:dev, then Packages / Premium Analytics / UI / DateFiltersPanel.

TranslatedRussian, TranslatedDutch and TranslatedGerman install real WordPress.org language packs through setLocaleData, so labels come from the actual __() path. Each renders the bar at 960 / 782 / 600 / 360 / 280px plus a resizable container.

1. Russian at 600px shows Last 24H 7D 30D 12M. On trunk it wraps to two rows.
2. English (DashboardFilters) at 600px keeps full labels. Same width, different tier, because the boundary is measured per locale.
3. Drag the resizable container across both boundaries. It should settle in one state at each width, never flicker between two.
4. 280px shows the custom trigger truncated with an ellipsis. On trunk it breaks mid-word across three lines.
5. All five rungs should show no wrapped preset row and no doubled divider at the left edge of a second row.

Also worth a pass in wp-admin on the dashboard, a report page, and post detail, since all three lost their wrapper ref: narrow the browser and confirm the presets shorten and then collapse.

Automated: pnpm run test in projects/packages/premium-analytics (199 suites, 1395 tests), plus pnpm run typecheck.

Follow-ups

• Real translations for the abbreviations. The tiers hold regardless, but until the packs carry Last 24H and friends, non-English users see English initials in the middle tier. Tracked on WOOA7S-1817.
• The probe's measurement is not unit tested: jsdom performs no layout, so getBoundingClientRect() returns 0, the probe bails, and the panel stays in full for the whole suite. The decision function and the label rendering are covered; the measurement is verified visually. Worth knowing before trusting a green run on this component.
• DateYearFilter still takes containerElement. Its panel lands in WOOA7S-1815, which should give it the same treatment.
• The year surface keeps flex-wrap: wrap because it has no abbreviated form. Revisit with WOOA7S-1815.
• WOOA7S-1818: All time orphans the existing All-time translation over a hyphen, and Custom needs _x() context — the French pack returns "Lien" for the bare msgid.

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

---

🔴 Action required: Please include detailed testing steps, explaining how to test your change, like so:

## Testing instructions:

* Go to '..'
*

---

🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so:

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

My PR adds *x* and *y*.

---

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!

[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 update/date-controls-responsive-labels branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/date-controls-responsive-labels

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/date-controls-responsive-labels

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

[jp-launch-control]

Code Coverage Summary

Coverage changed in 19 files. Only the first 5 are listed here.

File	Coverage	Δ%	Δ Uncovered
projects/packages/premium-analytics/packages/ui/src/date-filters-panel/date-filters-panel.tsx	0/45 (0.00%)	0.00%	15 💔
projects/packages/premium-analytics/packages/datetime/src/presets/primary.ts	69/69 (100.00%)	0.00%	0 💚
projects/packages/premium-analytics/packages/ui/src/date-range-filter/date-range-filter.tsx	9/9 (100.00%)	0.00%	0 💚
projects/packages/premium-analytics/packages/ui/src/date-range-layout.ts	6/6 (100.00%)	0.00%	0 💚
projects/packages/premium-analytics/packages/ui/src/date-range-quick-presets/date-range-quick-presets.tsx	17/20 (85.00%)	1.67%	0 💚

1 file is newly checked for coverage.

File	Coverage
projects/packages/premium-analytics/packages/ui/src/date-filters-panel/preset-row-probe.tsx	1/30 (3.33%) 💔

Full summary · PHP report · JS report

_{If appropriate, add one of these labels to override the failing coverage check: Covered by non-unit tests Use to ignore the Code coverage requirement check when E2Es or other non-unit tests cover the code Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage.}

[kangzj]

Reviewed the diff, ran jp test js packages/premium-analytics (199 suites, green), pnpm run typecheck, and eslint on the changed files — all clean.

Also verified the responsive behavior live in Storybook. Russian at 600px collapses to the abbreviated tier (Last 24H 7D 30D 12M) exactly as described, confirming the per-locale measurement is doing what the PR claims rather than a fixed breakpoint:

One non-blocking nit: the pre-existing CompactLayout story (English @ 360px, untouched by this PR) still carries the docblock "quick presets collapse to the compact select, like mobile layouts." With the new three-tier model, English at 360px now renders the abbreviated pill tier, not the select — the comment (and the story) no longer demonstrate what the name promises:

Worth a follow-up to either narrow the story's width or update its description so it still exercises the select tier. Doesn't block — everything else checks out.

[chihsuan]

Great work! @retrofox Overall looks good.

One thing I noticed: the probe and the real trigger can end up measuring two different labels.

After selecting and applying a custom range, clicking a preset pill does not change the custom-range trigger back to “Custom”. It continues to display the previously applied date range.

Also, the probe measures the shorter “Custom” label. This leaves roughly 90px of width unaccounted for, causing the UI to overlap or overflow.

See recording below:

Screen.Recording.2026-08-03.at.1.03.59.PM.mov

[retrofox]

Thanks for the review, Chi.

After selecting and applying a custom range, clicking a preset pill does not change the custom-range trigger back to “Custom”. It continues to display the previously applied date range.

This is intentional. I defined it this way in case the user wants to switch back to the last custom date range. I think it can be a valid use case. We can change the behavior if we consider it confusing, though.

[retrofox]

The probe and the trigger already shared the label helper.

What they did not share was one of its inputs: the trigger kept rememberedCustomRange in local state inside DateRangePopover, while the probe re-derived it from props, where it returns to null as soon as the applied preset stops being custom.

So after applying a custom range and clicking a preset, the trigger rendered the formatted range and the probe resolved to "Custom". That is your 90px apporx.

DateFiltersPanel now owns the remembered range and passes it down. The probe can only see props, so local state in the popover was invisible to it by construction. One source, no drift. Two tests pin the range arriving as a prop.

Worth knowing when you retest: the probe now measures the wide label whenever a custom range is remembered, so the presets shorten earlier and stay shortened after switching back to a preset.

That is the measurement being accurate, not a regression.

[chihsuan]

I think it can be a valid use case. We can change the behavior if we consider it confusing, though.

Thanks for clarifying! It may be worth checking with @ederrengifo, as the behavior appears to be different on the demo site. Agreed we can update it in a follow-up if needed.

Worth knowing when you retest: the probe now measures the wide label whenever a custom range is remembered, so the presets shorten earlier and stay shortened after switching back to a preset.

Thanks, tested well now. LGTM! 🚀

[dognose24]

Approving — I went through the probe design, the resolver, and the stories, and this is excellent work. Verified along the way:

• The unconditional double-render probe is the right answer to the oscillation problem, and the rounding directions pair correctly (probe ceils demand, panel floors supply — conservative on both sides, so sub-pixel jitter can't flip the mode).
• resolvePresetLabelMode's tests are a model: the every-tier-reachable set test and the monotonicity property (including the degenerate abbreviated > full widths) pin exactly the failure modes a boundary-only suite would miss.
• No stray MOBILE_CONTAINER_WIDTH_THRESHOLD references remain; isCompact survives only as labelMode === 'select'.
• The abbreviated pills carrying the full label as aria-label, and the whole group switching together, are both the right calls.
• Spot-checked the call-site cleanup: all the removed containerElement wrappers were indeed passing the panel's own immediate wrapper back.

One finding from testing the storybook stories, worth addressing here since this PR is what makes it reachable:

The custom trigger's font size still hangs on a fixed viewport breakpoint. .date-filters-panel-button gets max(md, 16px) below a @media (min-width: 600px) query (pre-existing, date-range-popover/date-range-filter.scss). On trunk that mismatch was unreachable in the app: the container is always narrower than the viewport, so below 600px viewport the panel was already in select mode and 16px matched the select. With the middle tier, full/abbreviated pills now survive into that zone — e.g. viewport 599px with the panel at ~560px keeps full 13px pills next to a 16px trigger. (In storybook it flips when the canvas iframe crosses 600px — around a 900px outer viewport with the sidebar open.)

Suggestion, in the spirit of the rest of this PR — key it to the panel's measured state instead of the viewport, and the media query goes away:

.date-filters-panel-button {
	font-size: var(--wpds-typography-font-size-md);
}

.date-filters-panel.is-compact .date-filters-panel-button {
	font-size: max(var(--wpds-typography-font-size-md), 16px);
}

The trigger then matches the pills whenever it shares the row with them, and matches the 16px select exactly when the row collapses — which also retires the last width constant this PR's own rationale argues against. Fine as a fast-follow if you'd rather keep this PR frozen.

Screenshots

Viewport 600px — abbreviated pills and the Custom trigger aligned at 13px

Viewport 599px — the media query fires: Custom jumps to 16px beside the 13px pills

Viewport 462px — select mode; both dropdowns at 16px, where the sizes align again

[retrofox]

Thanks, folks. We'll continue polishing the implementation in follow-ups. Thanks for your review 🙇‍♂️