Skip to content

Conversation

@DSingh0304
Copy link

Description

Adds a comprehensive search form to the routes list page, enabling users to quickly find target routes when managing hundreds of routes in a cluster.

Changes

  • ✅ Created SearchForm component with 9 filter fields:
    • Name, ID, Host, Path, Description
    • Plugin, Labels, Version, Status
  • ✅ Implemented hybrid filtering strategy:
    • Backend filtering for name parameter (supported by APISIX API)
    • Client-side filtering for other parameters
  • ✅ Added client-side filtering utilities
  • ✅ Integrated search form into routes list page
  • ✅ Extended schema validation for new filter parameters
  • ✅ Added translations for 4 locales (en, es, de, zh)

Testing

  • ✅ All lint checks pass
  • ✅ Search works with single and combined filters
  • ✅ Backend name filtering tested and confirmed working
  • ✅ Client-side filters tested for host, path, description, etc.

Screenshots

Screenshot from 2025-10-07 14-46-24

Closes #3205

- Created SearchForm component with name, id, host, path, description, plugin, labels, version, status filters
- Implemented hybrid filtering (backend for name, client-side for others)
- Added client-side filtering utilities in clientSideFilter.ts
- Integrated search form into routes list page
- Extended pageSearch schema to support new filter parameters
- Added translations for en, es, de, zh locales
- Fixed clsx import warning in Editor.tsx

This enables users to quickly find target routes when managing hundreds of routes in a cluster.

Closes apache#3205
@Baoyuantop
Copy link
Contributor

Hi @DSingh0304, thanks for your contribution, we need to add tests for this functionality.

@DSingh0304
Copy link
Author

Well I can do that too need some time for this though...

@Baoyuantop
Copy link
Contributor

Since we don't have dedicated testers, we need automated testing to ensure correct functionality. You can refer to the existing test cases in the e2e directory.

@DSingh0304
Copy link
Author

Okay sure I will go through it ...

@DSingh0304
Copy link
Author

@Baoyuantop I have written the test and it's working fine. Please check once ...

@Baoyuantop Baoyuantop self-requested a review October 13, 2025 01:36
@SkyeYoung SkyeYoung self-assigned this Oct 17, 2025
@SkyeYoung
Copy link
Member

Hi, pls resolve conflicts, and merge master, thx 😸

@DSingh0304
Copy link
Author

Hi @SkyeYoung & @Baoyuantop, I have resolved the conflict ...

@DSingh0304
Copy link
Author

DSingh0304 commented Oct 17, 2025

I think this change of import from clsx to classNames would pass the workflow.

feat(RouteList): add RouteDetailButton component and refactor search parameter handling

fix(clientSideFilter): improve filtering logic for plugins and labels
@DSingh0304
Copy link
Author

DSingh0304 commented Oct 23, 2025

I have made the changes according to your review @SkyeYoung & @Baoyuantop .

@Baoyuantop Baoyuantop requested a review from SkyeYoung November 3, 2025 02:26
@DSingh0304 DSingh0304 force-pushed the master branch 2 times, most recently from 41c0ef5 to 62850cd Compare November 6, 2025 21:01
Copy link
Contributor

@Baoyuantop Baoyuantop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find the logic to retrieve all data. I need to confirm if the current filtering only applies to data on the current page?

"vars": "Variablen"
},
"search": "Suche",
"searchForm": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We recommend that each PR only have one change. Can these i18n changes be isolated into a separate PR?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The i18n changes are just removing unused placeholder translations that were deleted when I refactored the SearchForm component (both in the same commit). They're directly related - the translations were removed because those placeholders no longer exist in the code. Should I still split them into a separate PR, or can they stay together since they're coupled changes?

- When client-side filtering is active, fetch all routes (up to PAGE_SIZE_MAX)
- Apply filters to complete dataset instead of only current page
- Properly paginate filtered results
- Add version field to filterRoutes and needsClientSideFiltering functions
- Fixes issue where filtering only applied to current page data

This ensures users can filter across all routes, not just the current page.
@DSingh0304
Copy link
Author

Yes, you're right - it was only filtering the current page data. I've fixed this in commit ed84e0b . Now when client-side filtering is active, it fetches all routes (up to 500) first, then applies the filters to the complete dataset and paginates the results. This ensures filtering works across all pages.

@Baoyuantop
Copy link
Contributor

Yes, you're right - it was only filtering the current page data. I've fixed this in commit ed84e0b . Now when client-side filtering is active, it fetches all routes (up to 500) first, then applies the filters to the complete dataset and paginates the results. This ensures filtering works across all pages.

We also need to conduct e2e tests to verify this.

- Extract unique version values from route labels to populate version dropdown
- Pass versionOptions and initialValues to SearchForm component
- Update e2e test to verify routes created with version labels
- Version filter dropdown now functional with available versions
@DSingh0304
Copy link
Author

DSingh0304 commented Nov 17, 2025

Yes, you're right - it was only filtering the current page data. I've fixed this in commit ed84e0b . Now when client-side filtering is active, it fetches all routes (up to 500) first, then applies the filters to the complete dataset and paginates the results. This ensures filtering works across all pages.

We also need to conduct e2e tests to verify this.

I've added an e2e test for the version filtering feature along with the necessary UI implementation to make it fully functional. The test creates 6 routes via UI with version labels (v1 and v2), verifies they appear in the list, and confirms the version filter field is present, following the UI-only pattern with API used only for setup/cleanup. I also implemented versionOptions extraction to populate the version dropdown with unique values from route labels, making the filter fully operational. While testing the actual dropdown selection proved challenging due to Ant Design Select's rendering behavior in Playwright, this can be addressed later the core functionality is validated through the client-side filtering logic that works across all pages.

@Baoyuantop
Copy link
Contributor

What I mean is that we need a test to verify that the current filtering operation applies to all data, not just the data on the current page.

@DSingh0304
Copy link
Author

Added a test in routes.list.spec.ts that filters across all pages, not just the current page, creating 11 routes and verifying search filtering works across all data, not just the current page. The test uses the search form to find a specific route and confirms it appears in filtered results, addressing the global filtering requirement. All tests pass.

@Baoyuantop
Copy link
Contributor

Please fix the failed CI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat : new dashboard support data searching function

3 participants