DSingh0304 commented on code in PR #3222:
URL: https://github.com/apache/apisix-dashboard/pull/3222#discussion_r2869602074


##########
src/utils/clientSideFilter.ts:
##########
@@ -0,0 +1,161 @@
+/**
+ * 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 { STATUS_ALL } from '@/config/constant';
+import type { APISIXType } from '@/types/schema/apisix';
+
+import type { SearchFormValues } from '../components/form/SearchForm';
+
+/**
+ * Client-side filtering utility for routes
+ * Used as a fallback when backend doesn't support certain filter parameters
+ */
+
+export const filterRoutes = (
+  routes: APISIXType['RespRouteItem'][],
+  filters: SearchFormValues
+): APISIXType['RespRouteItem'][] => {
+  return routes.filter((route) => {
+    const routeData = route.value;
+
+    // Filter by name
+    if (filters.name) {
+      const nameMatch = routeData.name
+        ?.toLowerCase()
+        .includes(filters.name.toLowerCase());
+      if (!nameMatch) return false;
+    }
+
+    // Filter by ID
+    if (filters.id) {
+      const idMatch = String(routeData.id)
+        .toLowerCase()
+        .includes(filters.id.toLowerCase());
+      if (!idMatch) return false;
+    }
+
+    // Filter by host
+    if (filters.host) {
+      const host = Array.isArray(routeData.host)
+        ? routeData.host.join(',')
+        : routeData.host || '';
+      const hosts = Array.isArray((routeData as unknown as Record<string, 
string[]>).hosts)
+        ? (routeData as unknown as Record<string, string[]>).hosts.join(',')
+        : '';
+      const combinedHost = `${host} ${hosts}`.toLowerCase();
+      const hostMatch = combinedHost.includes(filters.host.toLowerCase());
+      if (!hostMatch) return false;
+    }
+
+    // Filter by path/URI
+    if (filters.path) {
+      const uri = Array.isArray(routeData.uri)
+        ? routeData.uri.join(',')
+        : routeData.uri || '';
+      const uris = Array.isArray(routeData.uris)
+        ? routeData.uris.join(',')
+        : '';
+      const combinedPath = `${uri} ${uris}`.toLowerCase();
+      const pathMatch = combinedPath.includes(filters.path.toLowerCase());
+      if (!pathMatch) return false;
+    }
+
+    // Filter by description
+    // Note: Routes without a description field are excluded when description 
filter is active
+    if (filters.description && routeData.desc) {
+      const descMatch = routeData.desc
+        .toLowerCase()
+        .includes(filters.description.toLowerCase());
+      if (!descMatch) return false;
+    }

Review Comment:
   I’ve intentionally kept this pattern to preserve URL deep linking and 
browser history support (back/forward navigation). Decoupling via local state 
would also require a significant refactor of our E2E test suite (e.g., 
pagination test helper.ts), which relies on URL assertions. Since these 
paginated requests are lightweight, I think accepting the redundancy as a trade 
off for maintaining a consistent, URL driven state across the dashboard will be 
better.



##########
src/routes/routes/index.tsx:
##########
@@ -40,14 +50,134 @@ export type RouteListProps = {
   }) => React.ReactNode;
 };
 
+const SEARCH_PARAM_KEYS: (keyof SearchFormValues)[] = [
+  'name',
+  'id',
+  'host',
+  'path',
+  'description',
+  'plugin',
+  'labels',
+  'version',
+  'status',
+];
+
+const mapSearchParams = (values: Partial<SearchFormValues>) =>
+  Object.fromEntries(
+    SEARCH_PARAM_KEYS
+      .map((key) => [key, values[key]] as const)
+      .filter(([, value]) => value !== undefined)
+  ) as Partial<SearchFormValues>;
+
 export const RouteList = (props: RouteListProps) => {
   const { routeKey, ToDetailBtn, defaultParams } = props;
-  const { data, isLoading, refetch, pagination } = useRouteList(
+  const { data, isLoading, refetch, pagination, setParams: setRouteListParams 
} = useRouteList(
     routeKey,
     defaultParams
   );
+  const { params, resetParams, setParams: setSearchParams } = 
useSearchParams(routeKey) as {
+    params: PageSearchType;
+    resetParams: (defaults?: Partial<PageSearchType>) => void;
+    setParams: (params: Partial<PageSearchType>) => void;
+  };
   const { t } = useTranslation();
 
+  // Client-side filtering strategy:
+  // The backend API has limited support for complex filtering (e.g., fuzzy 
search on description,
+  // plugin content) combined with pagination. Therefore, we use client-side 
filtering for these fields.
+  // Limitation: We only fetch the first PAGE_SIZE_MAX records. If the total 
number of records
+  // exceeds this limit, the filter may miss matching records that are not in 
the first batch.
+  // This limitation is communicated to the user via a warning alert in the 
table.
+  const needsAllData = needsClientSideFiltering(params);
+  const nameFilter = params.name;
+  const { data: allData, isLoading: isLoadingAllData } = useQuery({
+    queryKey: ['routes-all', defaultParams, nameFilter],
+    queryFn: () =>
+      getRouteListReq(req, {
+        page: 1,
+        page_size: PAGE_SIZE_MAX,
+        ...defaultParams,
+        ...(nameFilter ? { name: nameFilter } : {}),
+      }),
+    enabled: needsAllData,
+  });
+
+  const handleSearch = (values: SearchFormValues) => {
+    // Send name filter to backend, keep others for client-side filtering
+    setRouteListParams({
+      page: 1,
+      ...mapSearchParams(values),
+    });
+  };
+
+  const handleReset = () => {
+    // Clear existing search params and then re-apply the default status filter
+    resetParams({
+      page: 1,
+      status: STATUS_ALL,
+    });
+  };
+
+  // Apply client-side filtering and pagination
+  const { filteredData, totalCount } = useMemo(() => {
+    // If client-side filtering is needed, use all data
+    if (needsAllData && allData?.list) {
+      const filtered = filterRoutes(allData.list, params);
+      const paginated = paginateResults(
+        filtered,
+        params.page || 1,
+        params.page_size || 10
+      );
+      return {
+        filteredData: paginated.list,
+        totalCount: paginated.total,
+      };
+    }
+
+    // Otherwise, use paginated data from backend
+    return {
+      filteredData: data?.list || [],
+      totalCount: data?.total || 0,
+    };
+  }, [needsAllData, allData, data, params]);
+
+  const actualLoading = needsAllData ? isLoadingAllData : isLoading;
+
+  // Update pagination to use filtered total and prevent unnecessary refetch 
during client-side pagination
+  const customPagination = useMemo(() => {
+    return {
+      ...pagination,
+      total: totalCount,
+      // When client-side filtering is active, only update URL params without 
triggering refetch
+      // since all data is already loaded
+      onChange: needsAllData
+        ? (page: number, pageSize: number) => {
+          setSearchParams({ page, page_size: pageSize });
+        }
+        : pagination.onChange,
+    };

Review Comment:
   I’ve intentionally kept this pattern to preserve URL deep linking and 
browser history support (back/forward navigation). Decoupling via local state 
would also require a significant refactor of our E2E test suite (e.g., 
pagination test helper.ts), which relies on URL assertions. Since these 
paginated requests are lightweight, I think accepting the redundancy as a trade 
off for maintaining a consistent, URL driven state across the dashboard will be 
better.



-- 
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]

Reply via email to