refactor: filters refactor - Not urgent#3401
Closed
ogzhanolguncu wants to merge 5 commits intomainfrom
Closed
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
Contributor
|
Caution Review failedFailed to post review comments. Configuration used: CodeRabbit UI 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (1)
📝 WalkthroughWalkthroughThis change refactors the log filtering system by introducing a centralized, type-safe filter schema builder and a generic filter hook. It removes manual schema and filter logic, updates all filter-related code to use plural keys (e.g., Changes
Sequence Diagram(s)sequenceDiagram
participant UI
participant useFilters (generic hook)
participant buildQueryParams
participant API
UI->>useFilters: Get current filters from URL/query params
useFilters-->>UI: Return filters array and helpers
UI->>buildQueryParams: Build query payload with filters & timestamp
buildQueryParams-->>UI: Return query payload
UI->>API: Fetch logs/timeseries with query payload
API-->>UI: Return filtered log data
Possibly related PRs
Suggested reviewers
✨ 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 (
|
ogzhanolguncu
requested review from
chronark,
mcstepp and
perkinsjr
as code owners
Contributor
|
Thank you for following the naming conventions for pull request titles! 🙏 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (16)
apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/components/table/components/log-details/components/hooks/use-logs-query.ts(1 hunks)apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/components/table/logs-table.tsx(1 hunks)apps/dashboard/app/(app)/logs/components/charts/hooks/use-fetch-timeseries.ts(1 hunks)apps/dashboard/app/(app)/logs/components/charts/query-timeseries.schema.ts(0 hunks)apps/dashboard/app/(app)/logs/components/table/hooks/use-logs-query.ts(2 hunks)apps/dashboard/app/(app)/logs/components/table/query-logs.schema.ts(0 hunks)apps/dashboard/app/(app)/logs/filters.query-params.ts(1 hunks)apps/dashboard/app/(app)/logs/filters.schema.ts(1 hunks)apps/dashboard/app/(app)/logs/hooks/use-filters.ts(1 hunks)apps/dashboard/lib/filters/filter-builder.ts(1 hunks)apps/dashboard/lib/filters/filter-hook.ts(1 hunks)apps/dashboard/lib/trpc/routers/logs/query-logs/index.ts(1 hunks)apps/dashboard/lib/trpc/routers/logs/query-logs/utils.test.ts(0 hunks)apps/dashboard/lib/trpc/routers/logs/query-logs/utils.ts(1 hunks)apps/dashboard/lib/trpc/routers/logs/query-timeseries/index.ts(1 hunks)apps/dashboard/lib/trpc/routers/logs/query-timeseries/utils.ts(2 hunks)
💤 Files with no reviewable changes (3)
- apps/dashboard/app/(app)/logs/components/table/query-logs.schema.ts
- apps/dashboard/lib/trpc/routers/logs/query-logs/utils.test.ts
- apps/dashboard/app/(app)/logs/components/charts/query-timeseries.schema.ts
🔇 Additional comments (14)
apps/dashboard/lib/filters/filter-builder.ts (3)
14-42: Type definitions are well-structured.The use of marker interfaces with boolean flags for discriminated unions is a clean pattern. The type system provides good compile-time safety.
205-250: Well-implemented schema generation with proper field type handling.The
createApiQuerySchemafunction correctly handles all field types including special time fields, and the conditional pagination support is cleanly implemented.
118-122: ```shell
#!/bin/bashLocate the TConfigs definition and inspect its
operatorspropertyrg -n -C3 "type TConfigs" .
rg -n -C3 "interface TConfigs" .
rg -n -C3 "TConfigs.*operators" .</details> <details> <summary>apps/dashboard/lib/trpc/routers/logs/query-logs/index.ts (1)</summary> `1-1`: **Import path correctly updated to use centralized schema.** The change from component-specific schema to the centralized filters schema aligns with the refactoring objectives. </details> <details> <summary>apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/components/table/components/log-details/components/hooks/use-logs-query.ts (1)</summary> `16-17`: **Filter keys correctly pluralized to match new schema.** The change from `method`/`path` to `methods`/`paths` is consistent with the refactored filter schema structure. </details> <details> <summary>apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/components/table/logs-table.tsx (1)</summary> `219-220`: **Prefetch query parameters correctly updated.** The pluralization of filter keys in the prefetch query maintains consistency with the refactored schema. </details> <details> <summary>apps/dashboard/lib/trpc/routers/logs/query-timeseries/index.ts (1)</summary> `4-4`: **Excellent schema reuse with appropriate field omission.** The approach of reusing `queryLogsPayload` while omitting pagination fields (`limit` and `cursor`) for timeseries queries is clean and reduces code duplication. This maintains consistency across the codebase while adapting to specific endpoint requirements. Also applies to: 12-12 </details> <details> <summary>apps/dashboard/app/(app)/logs/components/charts/hooks/use-fetch-timeseries.ts (1)</summary> `4-8`: **Clean refactor to centralize query parameter construction.** The simplification to use `buildQueryParams` effectively removes code duplication and centralizes filter logic as intended by the PR objectives. </details> <details> <summary>apps/dashboard/lib/trpc/routers/logs/query-logs/utils.ts (1)</summary> `1-18`: **Consistent updates to align with the new filter schema.** The changes correctly update the import path, parameter type, and apply the plural naming convention for filter keys (`paths`, `methods`) as intended by the refactor. </details> <details> <summary>apps/dashboard/app/(app)/logs/components/table/hooks/use-logs-query.ts (1)</summary> `5-34`: **Effective simplification using the centralized query builder.** The replacement of manual query parameter construction with `buildQueryParams` successfully reduces code complexity while maintaining all hook functionality. </details> <details> <summary>apps/dashboard/app/(app)/logs/hooks/use-filters.ts (1)</summary> `1-4`: **Excellent implementation of the generic filter hook pattern.** This concise implementation perfectly demonstrates the PR's main objective - enabling easy creation of new filter hooks by simply passing a schema to `createUseFilters`. This pattern will significantly reduce code duplication across the codebase. </details> <details> <summary>apps/dashboard/lib/trpc/routers/logs/query-timeseries/utils.ts (1)</summary> `1-30`: **Consistent application of the filter schema refactor.** The updates correctly align with the new centralized schema, using appropriate type constraints with `Omit` and maintaining the plural naming convention for filter keys. </details> <details> <summary>apps/dashboard/app/(app)/logs/filters.query-params.ts (1)</summary> `25-75`: **Well-structured filter processing logic** The switch statement properly handles all filter types with appropriate type checking and error handling. The exhaustive check pattern on line 71 is a good practice for catching unhandled cases. </details> <details> <summary>apps/dashboard/app/(app)/logs/filters.schema.ts (1)</summary> `5-55`: **Clean schema refactoring with good separation of concerns** The refactoring to use `createFilterSchema` successfully centralizes filter configuration and reduces code duplication. The status color coding logic (lines 9-18) appropriately follows HTTP status code conventions. </details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
18 tasks
ogzhanolguncu
changed the title
This was referenced Jul 25, 2025
18 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR will help us bootstrap new filters easily, including zod schemas, nuqs params, and more. We'll be able to easily create new
useFiltersHooksjust by passing the generated filters, e.g.,export const useFilters = createUseFilters(logsSchema);To validate the idea, I tried refactoring the rate limits overview filters and hooks, and it worked great. I'm planning to refactor them next, or we can target any other filters or sections. This change will help us refactor dashboard filters gradually.
You can easily see the amount of duplicate code eliminated as a result of this PR.
Fixes # (issue)
If there is not an issue for this, please create one first. This is used to tracking purposes and also helps use understand why this PR exists
Type of change
How should this be tested?
/logspages.Checklist
Required
pnpm buildpnpm fmtconsole.logsgit pull origin mainAppreciated
Summary by CodeRabbit
method→methods,path→paths) for consistency across the dashboard.