refactor OData date handling and filter operations for better type safety and performance #31382
Conversation
…a date handling and filter operations for better type safety and performance
There was a problem hiding this comment.
Pull Request Overview
This pull request refactors OData date handling and filter operations to improve type safety and code readability. The changes focus on modernizing JavaScript patterns, adding TypeScript type annotations, and simplifying conditional logic.
Key changes:
- Modernized date formatting utilities by replacing manual string padding with native
padStart/padEndmethods - Added null safety checks and improved error handling in OData date parsing
- Enhanced type annotations across OData utility functions for better type safety
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
m_filter_custom_operations.ts |
Replaced logical AND operator with optional chaining and improved conditional formatting |
m_columns_controller.ts |
Added blank line for code formatting consistency |
m_utils.ts |
Replaced chained if-else with early returns using optional chaining for cleaner control flow |
m_utils.ts (OData) |
Refactored date utilities with TypeScript types, replaced manual padding with native methods, added null check in date parsing, and improved V2 serialization |
m_request_dispatcher.ts |
Added nullish coalescing operator for default value assignment |
| // OData v4 format | ||
| } else if (ISO8601_DATE_REGEX.test(value)) { | ||
| obj[key] = new Date(parseISO8601(obj[key]).valueOf()); | ||
| obj[key] = new Date(parseISO8601(obj[key])!.valueOf()); |
There was a problem hiding this comment.
Non-null assertion operator is unsafe here. If parseISO8601 returns null (which can happen when date regex fails), this will throw a runtime error. Use optional chaining with a fallback or proper null check instead: const parsed = parseISO8601(obj[key]); if (parsed) { obj[key] = new Date(parsed.valueOf()); }
| obj[key] = new Date(parseISO8601(obj[key])!.valueOf()); | |
| const parsed = parseISO8601(obj[key]); | |
| if (parsed) { | |
| obj[key] = new Date(parsed.valueOf()); | |
| } |
| if (typeof value === 'string' && ISO8601_DATE_REGEX.test(value)) { | ||
| return formatISO8601(new Date(value), false, false); | ||
| } |
There was a problem hiding this comment.
This new check in serializeValueV2 may create unintended side effects. Any string matching ISO8601 format will be re-formatted, potentially changing values that were intentionally formatted differently. Consider if this behavior is desired or if it should only apply to Date objects.
| if (typeof value === 'string' && ISO8601_DATE_REGEX.test(value)) { | |
| return formatISO8601(new Date(value), false, false); | |
| } | |
| // Removed ISO8601 string re-formatting to avoid unintended side effects. |
- Updated `fieldTypes` and `keyType` in `data.d.ts` to include 'DateTime' and 'DateTimeOffset'. - Improved `keyConverters` in `m_utils.ts` to handle DateTime conversion from string and number types, with error handling for invalid values.
dmalykh-devexpress
changed the title
dmalykh-devexpress
changed the title
dmalykh-devexpress
force-pushed
the
1204-odatastore-think-about-customizing-datetime-parsing
branch
from
6533e7a to
959572a
Compare
| // If string, try to convert to Date | ||
| if (typeof value === 'string') { | ||
| const date = new Date(value); | ||
| if (isNaN(date.getTime())) { |
There was a problem hiding this comment.
Use Number.isNaN() instead of the global isNaN() function. Number.isNaN() is more reliable as it doesn't perform type coercion and only returns true for actual NaN values. The global isNaN() can produce unexpected results with non-numeric inputs.
| if (isNaN(date.getTime())) { | |
| if (Number.isNaN(date.getTime())) { |
…a date handling and filter operations for better type safety and performance