feat(UniversalFilter): add date-range picker support

[alexquincy]

Summary

• Ports the quick-ranges + custom start/end datetime picker feature from meshery-cloud's homegrown filter component (ui/utility/custom-filter.tsx) into Sistent's UniversalFilter, so meshery-cloud's events/stats page (and any other consumer) can drop its local implementation entirely.
• New optional props on UniversalFilterProps: datePicker, selectedDateRange, setSelectedDateRange, quickDateRanges. Date-range changes apply immediately (independent of the existing dropdown filters' draft+Apply flow), matching the prior UX.
• Adds a src/base/DateTimePicker wrapper around @mui/x-date-pickers' DateTimePicker (with LocalizationProvider/AdapterDateFns baked in), following the existing base/ wrapping convention.
• New optional peerDependencies: @mui/x-date-pickers (^9.0.0) and date-fns (^4.0.0), both marked optional in peerDependenciesMeta since most consumers don't need this feature.
• New exported types: DateRange, QuickDateRangeOption.

Test plan

• TDD: wrote failing tests for the new date-range behavior first, watched them fail, then implemented
• npm run build completes successfully (CJS/ESM/DTS all succeed; DateRange/QuickDateRangeOption types confirmed present in dist/index.d.ts)
• npx jest — 15 suites / 319 tests pass
• npm run lint — clean

[gemini-code-assist]

Code Review

This pull request introduces date-range filtering capabilities to the UniversalFilter component, adding a new DateTimePicker base component and integrating @mui/x-date-pickers and date-fns. Feedback on these changes focuses on improving type safety and robustness: making the new dependencies required peer dependencies to avoid build-time resolution failures, validating manually entered dates to prevent state corruption, exposing hardcoded UI strings as props to support localization, and explicitly typing the DateTimePicker props with <Date>.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

According to the repository's general rules, if a component is exported from a main entry point, its dependencies should be defined as required peer dependencies rather than optional ones. Since UniversalFilter and DateTimePicker are exported from the main entry point and statically import @mui/x-date-pickers and date-fns, marking them as optional peer dependencies will cause build-time resolution failures for consumers whose bundlers attempt to resolve these static imports. Please remove them from peerDependenciesMeta to make them required peer dependencies.

References

1. If a component is exported from a main entry point, its dependencies should be defined as required peer dependencies rather than optional ones. This prevents build-time resolution failures for consumers who may not use the specific component but still have their bundlers attempt to resolve the static imports.

[gemini-code-assist]

When users manually type into the date-time picker, it can temporarily produce an invalid Date object (where isNaN(date.getTime()) is true). Propagating an invalid date to the state can cause rendering errors or API failures. Please add a check to ensure the date is valid before updating the state.

Suggested change

	const handleStartDateChange = (newStartDate: Date | null) => {
	if (!newStartDate || !selectedDateRange) return;
	setSelectedDateRange?.({
	startDate: newStartDate,
	endDate: newStartDate > selectedDateRange.endDate ? newStartDate : selectedDateRange.endDate
	});
	};
	const handleEndDateChange = (newEndDate: Date | null) => {
	if (!newEndDate || !selectedDateRange) return;
	setSelectedDateRange?.({
	startDate: newEndDate < selectedDateRange.startDate ? newEndDate : selectedDateRange.startDate,
	endDate: newEndDate
	});
	};
	const handleStartDateChange = (newStartDate: Date | null) => {
	if (!newStartDate || isNaN(newStartDate.getTime()) || !selectedDateRange) return;
	setSelectedDateRange?.({
	startDate: newStartDate,
	endDate: newStartDate > selectedDateRange.endDate ? newStartDate : selectedDateRange.endDate
	});
	};
	const handleEndDateChange = (newEndDate: Date | null) => {
	if (!newEndDate || isNaN(newEndDate.getTime()) || !selectedDateRange) return;
	setSelectedDateRange?.({
	startDate: newEndDate < selectedDateRange.startDate ? newEndDate : selectedDateRange.startDate,
	endDate: newEndDate
	});
	};

[gemini-code-assist]

To support internationalization (i18n) and localization, avoid hardcoding UI strings like 'Quick Ranges', 'Start', and 'End'. Instead, expose these strings as configurable props on UniversalFilterProps (e.g., quickRangesLabel, startDateLabel, endDateLabel) with default values to maintain backward compatibility.

References

1. Avoid hardcoding UI strings (such as button labels) in shared components. Expose these strings as configurable props to support internationalization (i18n) and localization.
2. When exposing UI strings as configurable props in shared components to support localization, provide a default value to maintain backward compatibility.

[gemini-code-assist]

Explicitly type MuiDateTimePickerProps with <Date> to ensure type safety for consumers. Since AdapterDateFns is baked in, the date type is always Date, and typing it explicitly ensures that onChange and value props are correctly typed as Date instead of unknown or any.

Suggested change

	const DateTimePicker = React.forwardRef<HTMLDivElement, MuiDateTimePickerProps>(
	(props, ref) => {
	const DateTimePicker = React.forwardRef<HTMLDivElement, MuiDateTimePickerProps<Date>>(
	(props, ref) => {