Mdms kpi

[ashish-egov]

Summary by CodeRabbit

Release Notes

• New Features

  • Enhanced data fetching for microplanning configurations, including DssKpiConfigs.
  • Updated searchDssChartV2 function to include a new configuration parameter for improved chart data retrieval.

• Improvements

  • Simplified chart filtering logic to include all charts from campaignConfig.
  • Refined state management and error handling in the PlanInbox component for better user experience.
  • Improved session data management in the App component to prevent data leakage.

• Bug Fixes

  • Adjusted prop formatting in the GenericKpiFromDSS component to enhance readability.

[coderabbitai]

📝 Walkthrough

📝 Walkthrough

Walkthrough

The changes involve modifications to the searchDssChartV2 function to include a new required parameter, config, alongside existing parameters. This adjustment necessitated updates in the useKpiDssSearch hook to accommodate the new parameter when invoking the function. Additionally, the PlanInbox component underwent minor formatting changes and enhancements in state management and data fetching logic. The index.js file also saw updates to the useCustomMDMS hook to include a request for DssKpiConfigs, alongside improved session data management.

Changes

File	Change Summary
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchDssChartV2.js	- Modified searchDssChartV2 to require a new config parameter. - Updated input validation and error messages. - Simplified chart filtering logic to include all charts. - Maintained error handling and control flow.
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js	- Added import for useMyContext and retrieved DssKpiConfigs from context. - Updated searchDssChartV2 call to include config parameter.
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/PlanInbox.js	- Adjusted props formatting for GenericKpiFromDSS. - Enhanced state management and effect hooks for data fetching. - Maintained existing error handling for API calls.
health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/index.js	- Modified useCustomMDMS to include a request for DssKpiConfigs. - Updated useEffect hooks for improved session data management.

Possibly related PRs

• added new hook for microplans search screen #1587: The useKpiDssSearch hook now includes the config parameter when calling searchDssChartV2, which is directly related to the changes made in the main PR where searchDssChartV2 was updated to require a config parameter.
• Added action bar for pop inbox screen #1622: The PopInbox component's updates include the use of the searchDssChartV2 function for fetching KPI data, linking it to the changes in the main PR.
• planInbox console #1623: The PlanInbox component's modifications involve the integration of the searchDssChartV2 function, which is relevant to the main PR's updates.
• ui fixes #1798: The CSS changes may relate to the visual presentation of KPIs, which are affected by the changes in the main PR.
• fixed plan inbox issues #1915: The updates in PlanInbox include logic that may interact with the KPI data fetched by searchDssChartV2, connecting it to the main PR.
• Changes in facility kpis #1939: The modifications to the DssChartConfig directly relate to the functionality of the searchDssChartV2 function, making it relevant to the main PR.

Suggested reviewers

• nipunarora-eGov

🐇 In the code, we hop and play,
New configs join us on the way!
With charts and hooks, we weave a tale,
In the microplan, we shall not fail.
So let’s embrace this change with cheer,
For better data is finally here! 🎉

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

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)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 3

🧹 Outside diff range comments (4)

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchDssChartV2.js (1)

Line range hint 11-24: Enhance error messages with search criteria

The error messages could be more helpful by including the values that were searched for. This would make debugging easier.

         const moduleConfig = config.find(config => config.module === module);
 
         if (!moduleConfig) {
-            console.error(`No DSS Chart configuration found for module: ${module}`);
+            console.error(`No DSS Chart configuration found for module: "${module}" in ${config.length} available configs`);
             throw new Error(`No DSS Chart configuration found for module: ${module}`);
         }
 
         // Find the configuration for the given campaignType
         const campaignConfig = moduleConfig.kpiConfig.find(kpi => kpi.campaignType === campaignType);
 
         if (!campaignConfig) {
-            console.error(`No DSS Chart configuration found for campaignType: ${campaignType}`);
+            console.error(`No DSS Chart configuration found for campaignType: "${campaignType}" in module: "${module}"`);
             throw new Error(`No DSS Chart configuration found for campaignType: ${campaignType}`);
         }

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/PlanInbox.js (3)

Line range hint 48-67: Optimize state management to reduce complexity and potential re-renders.

Consider the following optimizations:

1. Combine related state variables into a single object
2. Use useReducer for complex state updates
3. Memoize expensive computations

- const [villagesSlected, setVillagesSelected] = useState(0);
- const [showTab, setShowTab] = useState(true);
- const [jurisdiction, setjurisdiction] = useState([]);
- const [censusJurisdiction, setCensusJurisdiction] = useState([]);
- const [hierarchyLevel, setHierarchyLevel] = useState("");
- const [censusData, setCensusData] = useState([]);
- const [boundaries, setBoundaries] = useState([]);

+ const [planState, setPlanState] = useReducer(planReducer, {
+   villagesSelected: 0,
+   showTab: true,
+   jurisdiction: [],
+   censusJurisdiction: [],
+   hierarchyLevel: "",
+   censusData: [],
+   boundaries: [],
+ });

+ // Add a reducer function to handle state updates
+ function planReducer(state, action) {
+   switch (action.type) {
+     case 'SET_VILLAGES':
+       return { ...state, villagesSelected: action.payload };
+     case 'SET_JURISDICTION':
+       return { 
+         ...state, 
+         jurisdiction: action.payload,
+         censusJurisdiction: action.payload 
+       };
+     // Add other cases as needed
+     default:
+       return state;
+   }
+ }

---

Line range hint 147-187: Enhance error handling and loading state management.

The current error handling could be improved to provide better user feedback and error recovery:

1. Add error boundaries to isolate failures
2. Consolidate loading states
3. Implement retry mechanisms for failed API calls

+ import { ErrorBoundary } from 'react-error-boundary';

+ const ErrorFallback = ({ error, resetErrorBoundary }) => {
+   return (
+     <div role="alert">
+       <p>{t("SOMETHING_WENT_WRONG")}</p>
+       <pre>{error.message}</pre>
+       <button onClick={resetErrorBoundary}>{t("TRY_AGAIN")}</button>
+     </div>
+   );
+ };

+ // Consolidate loading states
+ const isLoading = 
+   isLoadingPlanObject ||
+   isPlanEmpSearchLoading ||
+   isLoadingCampaignObject ||
+   isWorkflowLoading ||
+   isProcessLoading ||
+   mutation.isLoading ||
+   isPlanWithCensusLoading ||
+   isCountPlanWithCensusLoading;

  return (
+   <ErrorBoundary
+     FallbackComponent={ErrorFallback}
+     onReset={() => {
+       refetchPlan();
+       refetchPlanWithCensus();
+     }}
+   >
      {isLoading ? (
        <Loader />
      ) : (
        // Component content
      )}
+   </ErrorBoundary>
  );

---

Line range hint 1-24: Optimize component performance through code splitting and memoization.

The component is handling too many responsibilities and could benefit from:

1. Splitting into smaller, focused components
2. Memoizing expensive computations
3. Reducing re-renders

+ import { memo, useMemo, useCallback } from 'react';

+ // Extract table columns configuration to a separate component
+ const TableColumns = memo(({ t, handleTimelineClick }) => {
+   return useMemo(() => [
+     // ... column definitions
+   ], [t, handleTimelineClick]);
+ });

+ // Extract filter section to a separate component
+ const FilterSection = memo(({ 
+   activeFilter,
+   onFilter,
+   clearFilters,
+   selectedFilter 
+ }) => {
+   return (
+     <InboxFilterWrapper
+       options={activeFilter}
+       onApplyFilters={onFilter}
+       clearFilters={clearFilters}
+       defaultValue={{ [selectedFilter]: activeFilter[selectedFilter] }}
+     />
+   );
+ });

const PlanInbox = () => {
  // ... existing code

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE

📥 Commits

Reviewing files that changed from the base of the PR and between 61dd04e and 301f631.

📒 Files selected for processing (4)

• health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchDssChartV2.js (2 hunks)
• health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js (1 hunks)
• health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/PlanInbox.js (1 hunks)
• health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/index.js (1 hunks)

🧰 Additional context used

📓 Path-based instructions (4)

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchDssChartV2.js (1)

Pattern **/*.js: check

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js (1)

Pattern **/*.js: check

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/PlanInbox.js (1)

Pattern **/*.js: check

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/index.js (1)

Pattern **/*.js: check

📓 Learnings (1)

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/PlanInbox.js (1)

Learnt from: rachana-egov
PR: egovernments/DIGIT-Frontend#1847
File: health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/PlanInbox.js:308-314
Timestamp: 2024-11-18T04:35:51.535Z
Learning: In `PlanInbox.js`, the variable `planWithCensus?.StatusCount[selectedFilter]` is always defined in the given context, so null checks are unnecessary.

🔇 Additional comments (7)

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js (4)

Line range hint 1-24: Overall implementation looks good with minor improvements needed

The changes to include DssKpiConfigs are well-structured and maintain the hook's functionality. The implementation:

1. ✅ Properly retrieves config from context
2. ✅ Correctly passes all parameters to searchDssChartV2
3. ✅ Maintains existing query functionality

Consider the suggested improvements for error handling and caching strategy, but otherwise, the changes look good.

---

Line range hint 13-18: Enhance error handling and consider caching strategy

1. The current error handling only logs to console. Consider:
   • Proper error reporting to monitoring systems
   • User-friendly error handling
2. Setting both cacheTime and staleTime to 0 means no caching. Consider if this is intentional or if some caching would be beneficial.

Let's verify the searchDssChartV2 implementation to ensure it properly handles the new config parameter.

✅ Verification successful

Error handling is appropriate, but caching strategy needs review

The implementation of searchDssChartV2 shows proper error handling with:

• Input validation with descriptive error messages
• Configuration validation with specific error messages
• API error handling with proper error propagation
• Structured try-catch blocks with error transformation

However, the caching strategy in the React Query setup (cacheTime: 0, staleTime: 0) might need reconsideration as:

• The implementation makes multiple parallel API calls for visualization codes
• The API responses could be cached briefly to improve performance
• The useCache: false in the service implementation reinforces this no-cache approach

Recommendations:

• Consider setting reasonable cache times (e.g., 30 seconds) to prevent unnecessary API calls
• Keep error handling as is since it's well implemented

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify searchDssChartV2 implementation
# Expected: Find the implementation and verify it handles the config parameter

# Search for searchDssChartV2 implementation
ast-grep --pattern 'const searchDssChartV2 = $_' || ast-grep --pattern 'function searchDssChartV2($_)'

# Look for related test files
fd "searchDssChartV2.test" --type f

Length of output: 17322

---

2-2: Verify the context utility implementation

Let's ensure the context utility exists and properly exports the useMyContext hook.

✅ Verification successful

The context utility is properly implemented

The useMyContext hook is correctly exported from ../utils/context.js and provides access to the context state and dispatch function through React's Context API. The implementation follows React best practices for context management.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the context utility implementation
# Expected: Find the useMyContext export in the context utility

# Check if the context utility exists and exports useMyContext
ast-grep --pattern 'export { useMyContext }' || ast-grep --pattern 'export const useMyContext'

# Verify the file exists
fd "context.js" --type f

Length of output: 1007

---

Script:

#!/bin/bash
# Let's check the content of the context.js file in the microplan module
cat "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/utils/context.js"

# Also search for any useMyContext definition in the codebase
ast-grep --pattern 'const useMyContext = $_'

Length of output: 1628

---

6-6: Verify DssKpiConfigs structure and initialization

The code assumes DssKpiConfigs exists in the context state. Let's verify its structure and initialization.

Also applies to: 11-11

✅ Verification successful

Let me gather more information about the context initialization and usage.

---

Let me try one more search to understand how DssKpiConfigs is being used and initialized.

---

Let me check one final aspect about the initialization and reducer.

---

Based on the gathered information, I can now provide the final response:

DssKpiConfigs is properly initialized through MDMS

The code shows that DssKpiConfigs is properly initialized through the MDMS (Master Data Management System) configuration. It is:

• Loaded as part of the MDMS data fetch in the employee/index.js file
• Included in the MDMS modules list: { name: "DssKpiConfigs" }
• Dispatched to the context state through the reducer action "MASTER_DATA"
• Properly accessed in useKpiDssSearch.js through the context state

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify DssKpiConfigs structure and initialization
# Expected: Find where DssKpiConfigs is defined and initialized in the context

# Search for DssKpiConfigs definition/usage
rg "DssKpiConfigs" -A 5

# Look for MDMS config related to DssKpiConfigs
fd "mdms-config" --type f --exec rg "DssKpiConfigs" {} \;

Length of output: 1733

---

Script:

#!/bin/bash
# Check the context provider and state initialization
ast-grep --pattern 'const $_ = createContext($$$)'

# Look for dispatch calls related to DssKpiConfigs
rg "dispatch.*DssKpiConfigs" -A 3

# Check the MDMS API call structure
rg "MDMS.search" -A 5

Length of output: 1316

---

Script:

#!/bin/bash
# Look for the MyContext provider implementation and state initialization
rg -l "MyContext.Provider" | xargs rg "MyContext.Provider" -B 5 -A 5

# Check for MDMS related configuration or initialization
rg "MDMS.*DssKpiConfigs" -B 2 -A 2

# Look for any state updates related to DssKpiConfigs
rg "setState.*DssKpiConfigs|reducer.*DssKpiConfigs" -B 2 -A 2

Length of output: 2432

---

Script:

#!/bin/bash
# Check the reducer and initial state in the context file
rg -l "initialState.*=|reducer.*=" | xargs rg "initialState.*=|reducer.*=" -B 2 -A 10

# Look for any DssKpiConfigs related action types
rg "type.*DssKpiConfigs" -A 2

# Check the employee index file where DssKpiConfigs is mentioned
cat health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/index.js

Length of output: 31411

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchDssChartV2.js (2)

Line range hint 1-116: Overall implementation looks good!

The changes maintain good error handling, separation of concerns, and improve flexibility by externally injecting configuration. The code is well-structured and follows good practices.

---

Line range hint 40-48: Verify removal of active charts filtering

The code no longer filters for active charts. Please confirm if this is intentional and that chart activation is now handled at the configuration level.

✅ Verification successful

Let me gather more information about the chart configuration structure specifically in the microplan module.

---

Let me try one more search to find any previous versions or related configuration files in the microplan module.

---

Let me check the DssChartConfig.js file that was found to understand how charts are configured.

---

Chart activation is handled at configuration level - removal of filtering is correct

After examining the DssChartConfig.js file, I can confirm that chart activation is indeed handled at the configuration level. Each chart in the configuration has an explicit active: true property, making runtime filtering unnecessary. The removal of active charts filtering from the code is correct as the configuration already ensures only active charts are included.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any references to chart activation in the codebase
rg -i "chart.*active|active.*chart" --type js

# Search for the configuration structure to understand where chart activation might be handled
ast-grep --pattern 'const $config = {
  $$$
  charts: [
    $$$
  ]
  $$$
}'

Length of output: 1125

---

Script:

#!/bin/bash
# Search for chart configuration in microplan module
rg -A 10 "campaignConfig.*charts" --type js

# Look for previous implementation to understand the change
git log -p -- health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/services/searchDssChartV2.js

# Search for any chart filtering logic in microplan
rg "charts.*filter" --type js health/micro-ui/web/micro-ui-internals/packages/modules/microplan/

Length of output: 1686

---

Script:

#!/bin/bash
# Search for any chart-related configuration files in microplan
fd -e js -e json . health/micro-ui/web/micro-ui-internals/packages/modules/microplan/ --exec rg -l "charts.*:.*\[" {}

# Look for campaign configuration structure
ast-grep --pattern 'const campaignConfig = {
  $$$
  charts: [
    $$$
  ]
  $$$
}'

# Search for any chart activation logic in the configuration
rg -B 5 -A 5 "charts.*=.*\[" health/micro-ui/web/micro-ui-internals/packages/modules/microplan/

Length of output: 401

---

Script:

#!/bin/bash
# Check the content of the chart configuration file
cat health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/DssChartConfig.js

# Look for any imports of this configuration file
rg -l "DssChartConfig" health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/

# Search for any active/inactive chart logic in the configuration
rg -B 2 -A 2 "active.*:.*" health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/configs/DssChartConfig.js

Length of output: 17561

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/pages/employee/index.js (1)

103-103: LGTM! Verify MDMS configuration exists.

The addition of DssKpiConfigs to the MDMS request follows the existing pattern and is properly integrated with the context state management.

Let's verify the MDMS configuration exists:

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE

📥 Commits

Reviewing files that changed from the base of the PR and between 301f631 and 6dbb090.

📒 Files selected for processing (1)

• health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js (1)

Pattern **/*.js: check

🔇 Additional comments (2)

health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/hooks/useKpiDssSearch.js (2)

2-2: Verify the context file path

The import path seems correct, but let's verify the existence of the context file.

✅ Verification successful

Import path is correct and the context hook exists

The import statement is valid as:

• The context file exists at the correct relative path: ../utils/context.js
• The file properly exports the useMyContext hook
• The hook is implemented as a proper React context consumer

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of the context file and its exports
# Expected: Find the context file and verify it exports useMyContext

# Check if the context file exists relative to this file's location
fd -p "utils/context.{js,jsx,ts,tsx}" "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src"

# Verify the export of useMyContext
ast-grep --pattern 'export { $$ useMyContext $$ }'

Length of output: 493

---

Script:

#!/bin/bash
# Let's try a different approach to verify the context file and its exports

# First, let's find the context file using simpler fd command
fd context "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/utils"

# Then let's check for useMyContext export using ripgrep
rg "export.*useMyContext" "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/utils" -l

# Also search for any definition of useMyContext
rg "useMyContext" "health/micro-ui/web/micro-ui-internals/packages/modules/microplan/src/utils" -A 2

Length of output: 797

---

Line range hint 13-17: Verify if zero cache settings are intentional

Setting both cacheTime and staleTime to 0 means React Query won't cache the results at all. This could lead to unnecessary API calls and potential performance issues.

✅ Verification successful

Zero cache settings are intentional and consistent with the module's pattern

Looking at the codebase, setting both cacheTime and staleTime to 0 is a deliberate pattern used consistently across the microplan and campaign-manager modules for real-time data requirements. Specifically:

• The same pattern (cacheTime: 0, staleTime: 0) is used in related hooks:
  • useSavedMicroplans.js
  • useSavedMicroplansWithCampaign.js
  • useGenerateIdCampaign.js
  • Various campaign-manager components

This indicates a deliberate design choice to always fetch fresh data for these analytics and campaign-related queries, which is reasonable given the real-time nature of the data being displayed.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Look for similar query patterns in the codebase
# Expected: Find other react-query usages to understand the caching strategy

# Search for react-query cache settings
rg -A 2 "useQuery.*cacheTime.*staleTime" --type js

Length of output: 52

---

Script:

#!/bin/bash
# Let's try a broader search for useQuery patterns to understand the caching strategy
rg "useQuery.*{" --type js -A 5

# Also search specifically for cacheTime and staleTime separately
rg "cacheTime:|staleTime:" --type js -A 2

Length of output: 23144