bito-code-review[bot] commented on code in PR #44527: URL: https://github.com/apache/superset/pull/44527#discussion_r4087057540
########## superset-frontend/src/filters/components/DateRange/utils.ts: ########## @@ -0,0 +1,39 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +import dayjs, { Dayjs } from 'dayjs'; + +export const DATE_FORMAT = 'YYYY-MM-DD'; +export const RANGE_SEPARATOR = ' : '; + +export type DateRangeValue = [Dayjs | null, Dayjs | null] | null; + +export function parseTimeRange(value?: string | null): DateRangeValue { + if (!value) return null; + const [start, end] = value.split(RANGE_SEPARATOR); + const startDate = dayjs(start); + const endDate = dayjs(end); + if (!startDate.isValid() || !endDate.isValid()) return null; Review Comment: <!-- Bito Reply --> The suggestion is appropriate and improves the code by preventing a potential bug where a single date without a separator could be incorrectly parsed as a range. By checking the number of parts before parsing, the function correctly returns `null` for invalid input formats, ensuring more robust date range handling. **superset-frontend/src/filters/components/DateRange/utils.ts** ``` const [start, end] = value.split(RANGE_SEPARATOR); if (!start || !end) return null; const startDate = dayjs(start); const endDate = dayjs(end); ``` ########## superset-frontend/src/constants.ts: ########## @@ -200,6 +200,7 @@ export enum FilterPlugins { Time = 'filter_time', TimeColumn = 'filter_timecolumn', TimeGrain = 'filter_timegrain', + DateRange = 'filter_date_range', Review Comment: <!-- Bito Reply --> The suggestion provided by the reviewer is appropriate and addresses a functional gap where the new filter type was selectable in the UI but not handled in the report generation logic. Applying this change ensures that the report correctly processes the filter and emits the expected data, preventing it from being dropped. **superset-frontend/src/constants.ts** ``` Time = 'filter_time', TimeColumn = 'filter_timecolumn', TimeGrain = 'filter_timegrain', + DateRange = 'filter_date_range', ``` ########## superset-frontend/src/features/alerts/AlertReportModal.tsx: ########## @@ -1699,6 +1706,28 @@ const AlertReportModal: FunctionComponent<AlertReportModalProps> = ({ /> ); } + if (filterType === 'filter_date_range') { + return ( + <RangePicker + value={parseTimeRange(filterValues?.[0])} Review Comment: <!-- Bito Reply --> The suggestion to use the `DATE_FORMAT` constant instead of the hardcoded `'YYYY-MM-DD'` string is appropriate. It improves maintainability by ensuring the picker format remains consistent with the format used by `parseTimeRange` and `formatTimeRange` throughout the module. **superset-frontend/src/features/alerts/AlertReportModal.tsx** ``` <RangePicker value={parseTimeRange(filterValues?.[0])} format={DATE_FORMAT} ``` ########## superset-frontend/src/features/alerts/AlertReportModal.tsx: ########## @@ -1699,6 +1706,28 @@ const AlertReportModal: FunctionComponent<AlertReportModalProps> = ({ /> ); } + if (filterType === 'filter_date_range') { + return ( + <RangePicker + value={parseTimeRange(filterValues?.[0])} + format="YYYY-MM-DD" + allowClear + onChange={dates => { + const timeRange = formatTimeRange(dates); + setNativeFilterData( + nativeFilterData.map((f: any) => + filter.nativeFilterId === f.nativeFilterId + ? { + ...f, + filterValues: [timeRange], + } Review Comment: <!-- Bito Reply --> The suggestion is correct and improves the code. By storing an empty array `[]` instead of `[undefined]` when the time range is cleared, the application correctly handles the filter state, preventing the save and validation logic from incorrectly treating the cleared filter as populated. **superset-frontend/src/features/alerts/AlertReportModal.tsx** ``` onChange={dates => { const timeRange = formatTimeRange(dates); setNativeFilterData( nativeFilterData.map((f: any) => filter.nativeFilterId === f.nativeFilterId ? { ...f, filterValues: timeRange ? [timeRange] : [], } : f, ), ); }} ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
