feat(new-webui): Sort search results by timestamp. #956
Conversation
|
""" WalkthroughThe sorting logic for the "timestamp" column in the search results table was updated from a basic boolean sorter to a custom comparator function. Default sort order was set to ascending, and the sort directions were modified to prevent users from cancelling sorting by cycling through a third state. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SearchResultsTable
User->>SearchResultsTable: Clicks "timestamp" column header
SearchResultsTable->>SearchResultsTable: Sorts rows using custom comparator (a.timestamp - b.timestamp)
SearchResultsTable-->>User: Displays sorted results (ascending or descending)
Note over SearchResultsTable: Sort cycles only between 'ascend' and 'descend'
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1)`**/*.{cpp,hpp,java,js,jsx,tpp,ts,tsx}`: - Prefer `false == ` rather than `!`.
🧬 Code Graph Analysis (1)components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx (1)
⏰ Context from checks skipped due to timeout of 90000ms (2)
🔇 Additional comments (2)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.{cpp,hpp,java,js,jsx,tpp,ts,tsx}`: - Prefer `false == ` rather than `!`.
**/*.{cpp,hpp,java,js,jsx,tpp,ts,tsx}: - Preferfalse == <expression>rather than!<expression>.
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: lint-check (macos-latest)
| sorter: (a, b) => a.timestamp - b.timestamp, | ||
| defaultSortOrder: "ascend", | ||
| // Specifying a third sort direction removes ability for user to cancel sorting. | ||
| sortDirections: ['ascend', 'descend', 'ascend'], |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Proper numeric sorting implementation with intentional UX behaviour.
The changes correctly implement client-side numeric sorting for timestamps:
- The custom sorter function
(a, b) => a.timestamp - b.timestampis appropriate for numeric timestamps and more accurate than the previous boolean sorter - Default ascending order provides a sensible starting state for chronological data
- The sort directions configuration intentionally removes the ability to cancel sorting, which aligns with the comment's explanation
Consider adding null/undefined handling in the sorter if timestamps could potentially be missing:
- sorter: (a, b) => a.timestamp - b.timestamp,
+ sorter: (a, b) => (a.timestamp || 0) - (b.timestamp || 0),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| sorter: (a, b) => a.timestamp - b.timestamp, | |
| defaultSortOrder: "ascend", | |
| // Specifying a third sort direction removes ability for user to cancel sorting. | |
| sortDirections: ['ascend', 'descend', 'ascend'], | |
| sorter: (a, b) => (a.timestamp || 0) - (b.timestamp || 0), | |
| defaultSortOrder: "ascend", | |
| // Specifying a third sort direction removes ability for user to cancel sorting. | |
| sortDirections: ['ascend', 'descend', 'ascend'], |
🤖 Prompt for AI Agents
In
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx
around lines 29 to 32, the sorter function currently assumes timestamps are
always present. To handle cases where timestamps might be null or undefined,
update the sorter to check for these values before subtracting. Implement logic
to treat missing timestamps consistently, such as placing them at the start or
end of the sorted list, ensuring the sorter does not throw errors or produce
incorrect order when encountering missing data.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx (1)
30-30: 🧹 Nitpick (assertive)Handle missing timestamps to avoid
NaN.The current sorter
a.timestamp - b.timestampwill yieldNaNif eithertimestampisnullorundefined. Consider a nullish fallback to maintain stable ordering:-sorter: (a, b) => a.timestamp - b.timestamp, +sorter: (a, b) => (a.timestamp ?? 0) - (b.timestamp ?? 0),This ensures records with missing timestamps sort predictably.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.{cpp,hpp,java,js,jsx,tpp,ts,tsx}`: - Prefer `false == ` rather than `!`.
**/*.{cpp,hpp,java,js,jsx,tpp,ts,tsx}: - Preferfalse == <expression>rather than!<expression>.
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx
🧬 Code Graph Analysis (1)
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx (1)
components/log-viewer-webui/client/src/typings/datetime.ts (1)
DATETIME_FORMAT_TEMPLATE(3-3)
🔇 Additional comments (1)
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx (1)
27-27: Default ascending sort order is set appropriately.Setting
defaultSortOrder: "ascend"ensures the timestamp column is initially sorted chronologically from oldest to newest, which aligns with expected UX for time‐based data.
| sortDirections: ["ascend", | ||
| "descend", | ||
| "ascend"], |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Simplify sortDirections or remove redundancy.
Explicitly setting ["ascend", "descend", "ascend"] mirrors AntD’s default cycle. To restrict toggling to just ascend↔descend, you can simplify:
-sortDirections: ["ascend", "descend", "ascend"],
+sortDirections: ["ascend", "descend"],Or omit sortDirections entirely if the default behaviour already meets requirements.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| sortDirections: ["ascend", | |
| "descend", | |
| "ascend"], | |
| sortDirections: ["ascend", "descend"], |
🤖 Prompt for AI Agents
In
components/log-viewer-webui/client/src/pages/SearchPage/SearchResults/SearchResultsTable/typings.tsx
around lines 32 to 34, the sortDirections array includes a redundant third
"ascend" value. Simplify this by either removing the last "ascend" to have
["ascend", "descend"] or omit the sortDirections property entirely if the
default AntD behavior suffices, to avoid unnecessary redundancy.
| { | ||
| dataIndex: "timestamp", | ||
| defaultSortOrder: "ascend", | ||
| key: "timestamp", | ||
| render: (timestamp: number) => dayjs(timestamp).format(DATETIME_FORMAT_TEMPLATE), | ||
| sorter: true, | ||
| sorter: (a, b) => a.timestamp - b.timestamp, | ||
|
|
||
| // Specifying a third sort direction removes ability for user to cancel sorting. | ||
| sortDirections: [ | ||
| "ascend", | ||
| "descend", | ||
| "ascend", | ||
| ], | ||
| title: "Timestamp", | ||
| width: 15, | ||
| }, |
There was a problem hiding this comment.
(optional: utterly nit-picking) since there're many fields already, i'd probably group the fields:
| { | |
| dataIndex: "timestamp", | |
| defaultSortOrder: "ascend", | |
| key: "timestamp", | |
| render: (timestamp: number) => dayjs(timestamp).format(DATETIME_FORMAT_TEMPLATE), | |
| sorter: true, | |
| sorter: (a, b) => a.timestamp - b.timestamp, | |
| // Specifying a third sort direction removes ability for user to cancel sorting. | |
| sortDirections: [ | |
| "ascend", | |
| "descend", | |
| "ascend", | |
| ], | |
| title: "Timestamp", | |
| width: 15, | |
| }, | |
| { | |
| dataIndex: "timestamp", | |
| key: "timestamp", | |
| title: "Timestamp", | |
| render: (timestamp: number) => dayjs(timestamp).format(DATETIME_FORMAT_TEMPLATE), | |
| width: 15, | |
| // Specifying a third sort direction removes ability for user to cancel sorting. | |
| defaultSortOrder: "ascend", | |
| sortDirections: [ | |
| "ascend", | |
| "descend", | |
| "ascend", | |
| ], | |
| sorter: (a, b) => a.timestamp - b.timestamp, | |
| }, |
There was a problem hiding this comment.
I would be happy to do this, but the linter will complain about sort keys
Description
PR adds ability to sort by timestamp.
I took a look at old webui, and It implemented server side sorting. I thought the idea of this is that it would requery, and you could get either the earliest or latest 1000 results.
After looking at it further, the server side sorting is only in the results cache, and not actually in clp, or clp-s. Like it dosent requery. As a results, the server side sorting dosent actually change the available results, and the same functionality can be achieved with client-side sorting.
To simplify until we have fancier queries, that can be resubmitted, I simply implemented client side sorting to achieve the same functionality, which is simpler. It's not that it would be hard, but this is simpler.
Checklist
breaking change.
Validation performed
Results can be sorted
Summary by CodeRabbit