Reviewing files that changed from the base of the PR and between ad5a330 and dcf17e3.

• components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/TimeDateInput.tsx (1 hunks)
• components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/index.module.css (2 hunks)
• components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/index.tsx (4 hunks)
• components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/utils.tsx (1 hunks)

• GitHub Check: package-image
• GitHub Check: lint-check (ubuntu-24.04)
• GitHub Check: lint-check (macos-15)

components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/index.module.css (1)

5-7: Scoped ant-select min-width looks reasonable

Targeting .timeRangeInputContainer :global(.ant-select) keeps the width constraint local to this control, which should stabilise the preset dropdown without unintended global side-effects. No issues from a styling or maintainability standpoint.

components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/index.tsx (2)

5-9: I'll help you verify this review comment about the ConfigProvider theming in the TimeRangeInput component. Let me start by examining the actual implementation.
<function_calls>

Read the TimeRangeInput component file to verify the implementation details

#!/bin/bash

First, let's find the exact file and read it

find . -path "*SearchPage/SearchControls/TimeRangeInput/index.tsx" -type f | head -1 | xargs wc -l


</function_calls>
<function_calls>

Read the full TimeRangeInput component to see the implementation

#!/bin/bash

Read the file - first check its size, then read it

FILE=$(find . -path "*SearchPage/SearchControls/TimeRangeInput/index.tsx" -type f | head -1)
if [ -n "$FILE" ]; then
cat -n "$FILE"
fi


</function_calls>
<function_calls>

Find the TimeDateInput component referenced in the review to understand the custom input wiring

#!/bin/bash

Look for TimeDateInput file

find . -name "TimeDateInput*" -o -name "timeDateInput*" | head -10


</function_calls>
<function_calls>

Check the Ant Design version in package.json to verify token compatibility

#!/bin/bash

Find package.json for the webui client and check antd version

find . -path "*webui/client/package.json" -type f | xargs cat | grep -A 2 -B 2 '"antd"'


</function_calls>

---

108-113: Ant Design DatePicker.RangePicker components.input contract is valid and documented.

The components={{ input: TimeDateInput }} pattern is a supported, documented feature in Ant Design across multiple versions (tested 4.1.1 and 5.18.3). The contract expects:

• components.input as string | React.ComponentType<any>
• Custom input component receives standard input props: value, onChange, onFocus, onBlur, onClick, onMouseDown, onSelect, and standard DOM/ARIA handlers

The code correctly wires the custom input and drives disabled state via timeRangeOption checks. Ensure TimeDateInput properly spreads or handles the standard input props forwarded by RangePicker.

components/webui/client/src/pages/SearchPage/SearchControls/TimeRangeInput/TimeDateInput.tsx (1)

1-7: Based on my verification through web search, the review comment is substantively correct. Here's what I confirmed:

1. React's behavior: React warns when non-standard props are spread onto native DOM elements (confirmed by React documentation).
2. The issue: If TimeDateInput spreads all props (including DATE_RANGE_PROP_KEY) onto a native <input>, React will trigger "unknown prop" warnings.
3. The fix: The proposed destructuring solution is the standard, correct pattern recommended by React to separate internal props from DOM-intended props.
4. AntD contract: DatePicker's custom input should receive React.InputHTMLAttributes<HTMLInputElement> (standard HTML input props only), not custom application-specific markers like DATE_RANGE_PROP_KEY.

The review comment's suggestion to destructure DATE_RANGE_PROP_KEY before spreading is aligned with React best practices and necessary to avoid runtime warnings.

Rewritten Review Comment:

---

Strip date-range marker before spreading props to native input

The display-text logic is solid, but spreading all AntD input props onto a native <input> also forwards the "date-range" marker (a custom non-DOM prop) to the DOM, triggering React's "unknown prop" warning and risking future incompatibilities.

Destructure DATE_RANGE_PROP_KEY before spreading to keep your rendering logic intact while avoiding invalid attributes on the DOM element:

-const TimeDateInput = (props: TimeDateInputProps) => {
-    const {value, [DATE_RANGE_PROP_KEY]: dateRange} = props;
+const TimeDateInput = (props: TimeDateInputProps) => {
+    const {
+        value,
+        [DATE_RANGE_PROP_KEY]: dateRange,
+        ...restProps
+    } = props;
@@
-    return (
-        <input
-            {...props}
-            readOnly={true}
-            value={displayText}/>
-    );
+    return (
+        <input
-            {...restProps}
-            readOnly={true}
-            value={displayText}/>
+    );

This preserves your custom text rendering and event handlers while conforming to Ant Design's contract for custom input components.

⛔ Skipped due to learnings

Learnt from: hoophalab
Repo: y-scope/clp PR: 1108
File: components/webui/client/src/pages/SearchPage/SearchControls/Presto/SqlQueryInput/index.tsx:15-15
Timestamp: 2025-07-18T20:00:50.288Z
Learning: In the y-scope/clp React webui client codebase, for Zustand store usage: use `useStore.getState().method` for callbacks since the output is not reactive and doesn't need state as a dependency in the hook, and use `useStore((state) => state.property)` with proper selectors for reactive components that need to re-render when state changes.