Hosting Dashboard: Add Date Range Controls #105235

coder-karen · 2025-08-15T16:40:11Z

Part of DOTCOM-14159

Proposed Changes

This PR adds a date range control, which is currently for use on the site logs page but is added as a component.
The date range 'button' is an ~~InputControl~~ Button -- design specs suggested a text control but then they were also suggesting that we should use the old implementation. However after a conversation in Slack - p1755018709178949-slack-C0982082MSR - I'm using the component available from @automattic/ui.
The component started as a simple MVP datepicker, but based on an example shared in Slack it now has similar functionality to the picker from before. Slack: p1755503128722479/1755018709.178949-slack-C0982082MSR
Several styles have been implemented to keep everything aligned as expected - mainly related to mobile rendering.

For follow-up:

More investigation on timezone differences. Story book additions. Additional tests.

Why are these changes being made?

The date range picker is needed for the site logs page, part of the Hosting Dashboard v2.

Testing Instructions

Open up the site logs page at http://calypso.localhost:3000/v2/sites/your-site/logs.
The date range picker button should be pre-selected for the past 7 days.
Test changing the days, and using presets, as well as selecting custom date ranges.
Make sure the dates in your logs are correct for the ranges given. Ideally this will be tested across several different timezones.
Note that other functionality on the logs page still hasn't been implemented such as views and actions, so it's expected that taking actions such as trying to sort won't work.

Screenshots:

Desktop:

Mobile:

Pre-merge Checklist

Has the general commit checklist been followed? (PCYsg-hS-p2)
Have you written new tests for your changes?
Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
Have you checked for TypeScript, React or other console errors?
Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
- For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

github-actions · 2025-08-15T16:40:23Z

Calypso Live (direct link)

	https://calypso.live?image=registry.a8c.com/calypso/app:build-152965

Jetpack Cloud live (direct link)

	https://calypso.live?image=registry.a8c.com/calypso/app:build-152965&env=jetpack

Automattic for Agencies live (direct link)

	https://calypso.live?image=registry.a8c.com/calypso/app:build-152965&env=a8c-for-agencies

…ck - see PR description for more

mirka · 2025-08-19T14:33:04Z

client/dashboard/components/date-range-picker/index.tsx

+							<InputControl
+								value={ label }
+								onChange={ () => {} }


This implementation is not accessible for a few reasons:

It's not accessibly labeled (a Tooltip only adds visual information).

A screen reader user will not be able to tell that the input has button-like handlers.

The first is easily fixable but the second is more of a fundamental problem. It should semantically be a button. Any reason we're bending over backwards to use an input element? It doesn't quite make sense to me even from a visual standpoint, since the text is not editable.

Thanks for digging in to this, and for these suggestions.

No, no reason for it to specifically be InputControl, other than it made sense to me at the time. The design specs suggested a TextControl which made less sense, but to me the logical next step was an InputControl. But button does make a lot more sense - I've updated this.

mirka · 2025-08-19T14:36:48Z

client/dashboard/components/date-range-picker/index.tsx

+										<TextControl
+											placeholder="YYYY-MM-DD"


How about we use a type="date"? The hardcoded "YYYY-MM-DD" is not great for i18n either.

Thanks for the suggestion -- updated!

Using "date" does have the interesting effect of meaning there are now two calendars for controlling the same thing. On one hand maybe there's no harm in allowing two methods to edit the same thing. On the other hand I do think it looks a little confusing.

Something that we can iterate on though.

ciampo · 2025-08-19T16:04:15Z

Some additional feedback on top of @mirka 's:

The list of presets should be given some additional semantics — for example, listbox + option
It looks like the code could be tidied up / modularized. For example, the from/to date inputs could be extracted instead of being repeated twice for small/large viewport layouts. Also the DropdownMenu's renderContent prop could be broken down so that fewer variables / components are declared each time the component re-renders.

Overall, I recommend taking a look at this Storybook example which already addresses many items of feedback left so far (ie. using a button for the dropdown trigger, using <InputControl type="date" /> for the date inputs, using listbox semantics for the range presets, automatically highlighting a preset if the user manually selects the corresponding dates, etc etc).

p-jackson

Thank you for working on this! I haven't tested the UI yet, but leaving some code-related comments.

client/dashboard/utils/datetime.ts

client/dashboard/sites/logs/index.tsx

p-jackson · 2025-08-19T23:32:45Z

client/dashboard/sites/logs/index.tsx

+			gmtOffset: s?.gmt_offset ?? 0,
+			timezoneString: s?.timezone_string ?? '',


It seems unfortunate that sometimes we have to use gmtOffset and sometimes timezoneString 😬 Do you have any info on when one is defined over the other? Maybe I'm misreading the code, but I'm interpreting it as it will either be one or the other.

I'm glad you asked! I've got a follow-up task for the calendar to add various improvements (including for eg. storybook, additional tests beyond those in datetime), and I added a note to look into the timezone functionality more.
It was a head scratcher for me, and as best I can tell from the research I've done gmt_offset will always exist (defaults to 0 if not set), but timezone_string can be empty when the site uses a numeric offset.
date_i18n apparently has issues with certain timezone settings such as numerical ones, which means that using timezone_string where possible should fix issues in those cases (eg. DST) - IANA zones (e.g., Europe/London) apparently embed DST transition rules.
As I understand, using 'TZDate' as suggested in the calendar package code doesn't help with this case anyway, though I've added it where possible.
For now I think some good testing across different timezones would be helpful, for the 'MVP' anyway.

Wow, today I learned how wild the return value of wp_timezone_string() is!

client/dashboard/sites/logs/dataviews/fields.tsx

client/dashboard/components/date-range-picker/index.tsx

… different child components, based on feedback

coder-karen · 2025-08-20T10:26:43Z

@mirka @ciampo @p-jackson thanks so much for the reviews here.

I should have addressed all the feedback with the new commits (or with comments to suggestions) at this stage.

I also have a follow-on task for more refinements with this Date Range Picker - including a story book example, more tests, and more research into the date and time functionality itself. Initially this was to be an MVP with the minimal date range picker functionality as needed, for follow up later, but the example shared in Slack inspired me to do as much as possible for the MVP so it has become a lot more complex than I anticipated. For new feedback it would be good to see what can be included in a follow-up, or what we should fix for an MVP. Thanks again for the deep dives!

client/dashboard/components/date-range-picker/index.tsx

p-jackson · 2025-08-21T02:44:22Z

client/dashboard/sites/logs/index.tsx

+			gmtOffset: s?.gmt_offset ?? 0,
+			timezoneString: s?.timezone_string ?? '',


Wow, today I learned how wild the return value of wp_timezone_string() is!

p-jackson · 2025-08-21T03:00:53Z

client/dashboard/components/date-range-picker/index.tsx

+										<TextControl
+											placeholder="YYYY-MM-DD"


Using "date" does have the interesting effect of meaning there are now two calendars for controlling the same thing. On one hand maybe there's no harm in allowing two methods to edit the same thing. On the other hand I do think it looks a little confusing.

Something that we can iterate on though.

p-jackson

Thanks for the improvements. Seems like a good place to merge and keep iterating on the logging interface IMO

arthur791004 · 2025-08-21T06:50:11Z

client/dashboard/components/date-range-picker/utils.ts

+import { formatDateWithOffset } from '../../utils/datetime';
+
+// Normalize/comparison helpers
+const startOfDay = ( date?: Date ) =>


It seems we can consider to use date-fns for these helpers 🙂

arthur791004 · 2025-08-21T06:52:12Z

client/dashboard/components/date-range-picker/index.tsx

+	gmtOffset,
+	timezoneString,
+}: DateRangePickerProps ) {
+	const locale = useLocale();


As a component, it would be better not to rely on this hook. Instead, the component should accept locale through props.

arthur791004 · 2025-08-21T06:53:39Z

client/dashboard/components/date-range-picker/index.tsx

+	const desktopLabelId = `presets-label-${ instanceId }-desktop`;
+
+	const label = useMemo(
+		() => formatLabel( start, end, locale, timezoneString, gmtOffset ),


This doesn't seem to be a heavy computation. Maybe we don't need to memo it 🤔

arthur791004 · 2025-08-21T06:53:52Z

client/dashboard/components/date-range-picker/index.tsx

+	);
+
+	// Reset internal draft state when key inputs change by remounting the inner component
+	const resetKey = useMemo(


arthur791004 · 2025-08-21T07:06:06Z

client/dashboard/components/date-range-picker/date-range-content.tsx

+	compositeActiveId: string | null;
+	setCompositeActiveId: ( id: string | null ) => void;
+	siteToday: Date;
+	siteTodayStr: string;


It seems weird that there is site concept here. Would it be better to call it today?

arthur791004 · 2025-08-21T07:09:24Z

client/dashboard/components/date-range-picker/style.scss

+    justify-content: center;
+    width: 100%;
+  }
+}


We need empty line at the end of file

arthur791004 · 2025-08-21T07:12:19Z

client/dashboard/components/date-range-picker/index.tsx

+								<span aria-hidden="true" className="daterange-input__text">
+									{ label }
+								</span>
+								<Icon icon={ calendar } size={ 24 } style={ { marginRight: 8, paddingLeft: 4 } } />


Can we provide the icon to button and set the position to right 🤔

arthur791004 · 2025-08-21T07:16:33Z

client/dashboard/components/date-range-picker/date-range-content.tsx

+						style={ { marginBottom: 16 } }
+					>
+						<VisuallyHidden id={ mobileLabelId }>{ __( 'Date range presets' ) }</VisuallyHidden>
+						<PresetsListbox


It looks weird on specific size

arthur791004 · 2025-08-21T07:17:50Z

client/dashboard/components/date-range-picker/date-range-content.tsx

+						as="div"
+						spacing={ 1 }
+						className="daterange-presets"
+						style={ { marginBottom: 16 } }


Instead of using marginBottom, would it be better to add another VStack and set the spacing 🤔

Also, can we move VStack to PresetsListbox itself? It seems the component needs it internally 🤔

arthur791004 · 2025-08-21T07:19:58Z

client/dashboard/components/date-range-picker/date-range-content.tsx

+			: { from: fromDraft, to: toDraft };
+
+	return (
+		<div style={ { padding: 12 } }>


Would it be better to use a VStack here to keep the spacing consistent instead of setting margins individually? 🤔

Add daterangecontrols for the site logs within hosting dashboard

0feb326

coder-karen self-assigned this Aug 15, 2025

coder-karen added the [Status] In Progress label Aug 15, 2025

coder-karen added 4 commits August 18, 2025 17:27

DateRange picker complete refactor, based on an example shared in Sla…

daa95be

…ck - see PR description for more

Add spacing and function comment to formatLabel function

7002851

Merge branch 'trunk' into add/hosting-dashboard-date-range-controls

1e717ef

Fix merge conflict - fix siteRoute import location

6e17c76

coder-karen marked this pull request as ready for review August 19, 2025 08:18

coder-karen requested a review from a team as a code owner August 19, 2025 08:18

matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Aug 19, 2025

coder-karen removed the [Status] In Progress label Aug 19, 2025

coder-karen requested review from ciampo, aduth and a team and removed request for ciampo and aduth August 19, 2025 08:18

mirka reviewed Aug 19, 2025

View reviewed changes

coder-karen added 2 commits August 19, 2025 17:09

Change calendaar InputControl to Button

72a9bb0

Add the date type to the TextControl instances, removing the placeholder

a01817b

p-jackson reviewed Aug 19, 2025

View reviewed changes

coder-karen added 5 commits August 20, 2025 09:11

Re-organizing date range component - using helpers, other components,…

269543d

… different child components, based on feedback

Date and timezone updates

ba3f93c

Avoid using useEffect to adjust state when props change

b8c50e6

Update datetime tests now that the datetime file has been updated

c4adc3b

Use TZDate when working with timezones, wherever possible

8cf2367

p-jackson approved these changes Aug 21, 2025

View reviewed changes

arthur791004 reviewed Aug 21, 2025

View reviewed changes

		gmtOffset: s?.gmt_offset ?? 0,
		timezoneString: s?.timezone_string ?? '',

Hosting Dashboard: Add Date Range Controls #105235

Are you sure you want to change the base?

Hosting Dashboard: Add Date Range Controls #105235

Conversation

coder-karen commented Aug 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed Changes

Why are these changes being made?

Testing Instructions

Pre-merge Checklist

Uh oh!

github-actions bot commented Aug 15, 2025 • edited by matticbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ciampo commented Aug 19, 2025

Uh oh!

p-jackson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

coder-karen commented Aug 20, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

p-jackson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

coder-karen commented Aug 15, 2025 •

edited

Loading

github-actions bot commented Aug 15, 2025 •

edited by matticbot

Loading