fix(analytics): give the date-range calendar its space, drop the dead panel width

[subodhr258]

What

The shared analytics date-range popover rendered nothing like the Figma Analytics Final flow. The calendar was squeezed to ~140px (19px-wide day cells, effectively unreadable) while the preset list sat at ~405px with most of it blank, the "Date Range" icon pushed to the far edge.

DateRangePicker is one component used on nine surfaces, so this fixes all of them at once.

Why it happened

WP sizes .components-popover__content to width: min-content, and neither column in .godam-daterange was pinned:

column	min-content	max-content	rendered
calendar	141px	300px	141px
presets	238px	974px	405px

The preset list's min-content width is large (WP floors .components-menu-item__item at 160px and pushes trailing icons out with margin-right: auto), so with min-content sizing the calendar absorbed the whole shortfall and collapsed.

What changed

Both columns are now fixed and non-shrinking, so the popover width is deterministic wherever it renders: calendar 314px, presets 188px, 8px apart as two rounded panels per the design. The day grid and weekday header run on fixed repeat(7, 40px) tracks and the calendar width carries its padding plus border, so every cell lands on an exact pixel boundary (measured: cell offsets 0, 40, 80 ... 240, weekday-centre delta 0.000px). Fractional 1fr tracks put the range band's edges on sub-pixels, which shows as hairlines between adjacent days.

• day grid drops its column gap, so a selected range paints one continuous band instead of stripes
• month grid renders only the weeks the month touches; a trailing all-next-month row was dead space (Figma shows five rows for a five-row month)
• Date Range icon moves to the left of its label, as designed
• hovering a selected endpoint no longer paints a 12% tint over it, which left the white day number unreadable (pre-existing contrast bug)
• month steppers get the bordered square frame from the design

No markup, props, data-test-ids, or query behaviour changed. Accent colours still follow --wp-admin-theme-color.

Testing

Verified live on godam-dev.local (Chrome, 1470px viewport) by opening every picker instance and measuring the rendered geometry. All ten report popover 518px / calendar 314px / presets 188px, no clipping and no scrollbars:

• Dashboard: viewers gauge, insights, playback performance, top videos, Reel Pops section
• Per-video analytics: insights, viewer retention, placements, video layer timeline, playback performance

The Reel Pops section picker is the godam-for-woo consumer that borrows this component through window.GoDAM, so the cross-plugin path is covered by the same verification.

Unit tests: monthGrid is now exported and covered for a 4-week month (Feb 2026), a 5-week month (Jul 2026) and a 6-week month (Aug 2026), plus an invariant that no month ends on a row of only next-month days. 12 tests pass; lint:js and lint:css clean.

Automation impact

data-test-id hooks are unchanged (*-toggle, *-panel, *-preset-<key>, *-custom). Suites that assert a fixed 42 day cells need updating to the per-month week count.

Screenshots

[Copilot]

Pull request overview

Note

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Adjusts the shared analytics DateRangePicker popover layout to match the Figma “Analytics Final” design by making the calendar/presets panels deterministic in width and refining the calendar grid rendering.

Changes:

• Refactors popover/panel SCSS to enforce fixed panel widths, update spacing, and improve range/hover visuals.
• Updates calendar grid generation to render only the weeks a month touches (instead of a fixed 6-row grid).
• Adds unit coverage for the new monthGrid behavior and exports it for testing.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.

File	Description
pages/analytics/components/DateRangePicker/style.scss	Enforces fixed two-panel layout and updates calendar/preset styling to match design.
pages/analytics/components/DateRangePicker/index.js	Changes monthGrid sizing logic; adds popover class passthrough; adjusts toggle icon position; exports monthGrid.
pages/analytics/components/DateRangePicker/index.test.js	Adds parameterized tests for the new variable-week monthGrid.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[KMchaudhary]

Review — analytics date-range picker

Really solid fix. The root-cause writeup matches what the CSS actually does (WP's min-content popover sizing collapsing the un-pinned calendar column), monthGrid's week-count is correct and well covered by the three-case + all-months-invariant tests, the DST-safe calendar arithmetic is preserved, iconPosition="left" is the right lever (MenuItem defaults it to "right"), and out-specifying WP's zero-padding rule with the extra .components-popover class is the correct call. A few minor, all non-blocking notes:

1. Panel drop-shadows clip against the 4px popover padding. style.scss:32 sets padding: 4px, but each panel's box-shadow: 0 2px 6px (:51) reaches ~8px below / ~6px sideways. When WP applies overflow: auto on .components-popover__content — as the comment at :25 notes it does — the outer few px of the shadow get clipped rather than "kept clear." It's a 6%-opacity shadow so barely visible, but the comment slightly overstates the guarantee; ~8px padding would actually satisfy it.

2. Focus ring can be occluded by adjacent day cells. Dropping the grid column gap (:118-121) means the day :focus-visible outline (2px + 1px offset ≈ 3px overhang, :139-142) now extends into the neighbouring cell with zero clearance. When that neighbour is a solid .is-endpoint or shaded .is-in-range cell (it paints later in DOM order) it covers the ring's edge during keyboard nav. Minor a11y polish — an inset ring (outline-offset: -1px) keeps it inside the 40px cell.

3. min-height: 40px on .components-menu-item__button (:66-68) is redundant. MenuItem already renders its Button with __next40pxDefaultSize, so preset rows are 40px by default; the rule (and its "more generously than the WP default" comment) isn't doing anything. Safe to drop.

Non-blocking observation: the variable row count means the calendar panel height now changes between 4/5/6-week months, so the popover reflows a little on month navigation. That's expected given the "only the weeks it touches" Figma goal — just flagging it's a behaviour change from the old fixed 42-cell height.

Overall LGTM; the notes above are all optional.

[KMchaudhary]

Review

Solid, well-scoped fix — the correctness of the core change holds up. I verified the monthGrid week-count formula (Math.ceil((first.getDay() + daysInMonth) / 7)) by hand against all three parametrized cases and the 12-month "never ends on an all-next-month row" invariant; it's provably minimal-and-sufficient for a Sunday-start grid. The DST-safe calendar arithmetic is preserved, iconPosition="left" is a real change (WP's MenuItem defaults iconPosition to "right", so this correctly moves the calendar glyph before the label), and the 314px = 7×40 + 2×(16+1) border-box math lands the columns on exact pixel boundaries as claimed. No correctness or regression issues in the JS.

A few low-severity polish/robustness notes, all in style.scss — none blocking:

1. Presets column i18n (&__presets, ~L56). Switching from min-width: 140px (grow-to-fit) to a fixed width: 188px plus .components-menu-item__item { min-width: 0 } means the column can no longer widen to its labels. Every label goes through __(), so a longer localized string (e.g. a translated "Date Range" / "All Time") will wrap to two lines within the fixed 188px rather than expand the column. Worth a quick check with a longer-locale build, or white-space: nowrap if wrapping is undesirable.

2. Stale comment (~L54). The comment // Preset list on the right, sized to its labels. now contradicts the code immediately below it (a fixed 188px). Suggest updating it to reflect the fixed width — it'll otherwise mislead the next maintainer.

3. Calendar title has no overflow guard (&__cal-title, ~L93). The month: 'long', year: 'numeric' title sits in a space-between header between two 30px steppers, now inside 280px of content. Most locales fit, but a long localized "Month YYYY" could wrap/overflow and shove the steppers. A white-space: nowrap + text-overflow: ellipsis (or min-width: 0 on the title) would harden it.

4. Popover coupling to a WP internal class (.components-popover__content, ~L28). The two-panel look depends on neutralizing this internal, non-contract class. A @wordpress/components bump that renames/restructures it would silently drop the panel chrome with nothing to catch it — acceptable (the file already reaches into .components-menu-item__*), just flagging the upgrade risk.

5. Shadow vs. popover padding (~L32). Content padding: 4px is thinner than each panel's 0 2px 6px shadow (~8px bottom reach). At the 1470px viewport you tested this is fine, but when WP applies its inline overflow: auto + max-height on a short viewport, the last panel's bottom shadow could be clipped or nudge a 1px scrollbar. Minor — bumping the bottom padding to ~8px would fully clear it.

Nit: the PR description says "No markup, props, data-test-ids, or query behaviour changed," but the diff does add the iconPosition prop and popoverProps.className (both harmless) — just for accuracy.

Nothing here blocks merge; items 1–2 are the ones I'd address before shipping.