Refactor FileBlock, FIleUpload, UserAvatar, UserHome and migrated to TanStack's query #10045
Conversation
…d, UserAvatar, and UserHome components
WalkthroughThis pull request focuses on refactoring data fetching across multiple components by replacing a custom query hook with the standard Changes
Sequence DiagramsequenceDiagram
participant Component
participant useQuery
participant query Utility
participant API
Component->>useQuery: Configure query
useQuery->>query Utility: Call with params
query Utility->>API: Make network request
API-->>query Utility: Return data
query Utility-->>useQuery: Process response
useQuery-->>Component: Provide data and state
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
src/components/Users/UserHome.tsx (1)
39-51: Handle error state in data fetchingCurrently, the component only handles the loading state and the absence of
userDatabut does not handle errors that might occur during the data fetching process. It's important to provide feedback to the user when an error occurs to improve the user experience.Consider adding error handling by checking for the
errorstate returned byuseQuery:const { data: userData, isLoading, error } = useQuery({ ... }); if (isLoading) { return <Loading />; } if (error) { return <div>Error fetching user details</div>; // Replace with a user-friendly error component }This ensures that users are informed if there's an issue retrieving the user details.
src/components/Files/FileUpload.tsx (1)
137-147: Addenabledoption touseQueryhooks to prevent unnecessary queriesThe
useQueryhooks foractiveFilesQueryandarchivedFilesQuerydo not have theenabledoption specified. IfassociatedIdis empty or invalid, these queries may run unnecessarily, leading to redundant API calls or potential errors.Include the
enabledoption to ensure the queries only execute whenassociatedIdis valid:useQuery({ queryKey: ["viewUpload", "active", type, associatedId, offset], queryFn: query(routes.viewUpload, { // ... }), + enabled: Boolean(associatedId), });Apply the same change to the
archivedFilesQuery:useQuery({ queryKey: ["viewUpload", "archived", type, associatedId, offset], queryFn: query(routes.viewUpload, { // ... }), + enabled: Boolean(associatedId), });This prevents unnecessary queries when
associatedIdis not available.Also applies to: 150-163
src/components/Users/UserAvatar.tsx (1)
31-38: Handle error state in data fetchingThe component currently only checks for the loading state and absence of
userData, but it doesn't handle errors that might occur during the data fetching process usinguseQuery. Including error handling improves the robustness of the component and provides better feedback to the user.Modify the code to handle errors by updating the destructured values and adding an error check:
const { data: userData, isLoading, error } = useQuery({ ... }); if (isLoading) { return <Loading />; } if (error) { return <div>Error loading user data</div>; // Replace with an appropriate error component }This ensures users are notified when there's an issue fetching the user data.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/components/Files/FileBlock.tsx(4 hunks)src/components/Files/FileUpload.tsx(4 hunks)src/components/Users/UserAvatar.tsx(3 hunks)src/components/Users/UserHome.tsx(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: cypress-run (1)
🔇 Additional comments (4)
src/components/Files/FileBlock.tsx (4)
1-1: LGTM! Clean transition to TanStack Query.The import changes correctly reflect the migration from a custom query hook to TanStack Query's official implementation.
Also applies to: 16-16
38-43: Excellent query key structure!The array-based query key structure with multiple elements (
path,file.id,fileManager.type,associating_id) provides excellent cache management and invalidation capabilities. This approach aligns with TanStack Query best practices.
94-94: LGTM! Correct data access pattern.The update to
fileData?.read_signed_urlcorrectly reflects TanStack Query's data structure, maintaining null safety with optional chaining.
37-48: Consider adding input validation for file.id.While the query implementation is solid, the fallback to an empty string for
file.idmight indicate missing validation. Consider validating the file ID before making the query.
|
@rithviknishad requesting for review :), Thank you |
…ery key structure and enhance data handling with React Query
|
@rithviknishad I believe, I have made the required changes, kindly look into it and let me know if I made a mistake : ) |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
src/components/Users/UserHome.tsx (2)
41-47: Consider memoizing the query key and making the enabled condition more explicit.The query implementation looks good, but could be improved for better performance and clarity.
- const { data: userData, isLoading } = useQuery({ - queryKey: ["getUserDetails", username], - queryFn: query(routes.getUserDetails, { - pathParams: { username }, - }), - enabled: Boolean(username), - }); + const queryKey = useMemo(() => ["getUserDetails", username], [username]); + const { data: userData, isLoading } = useQuery({ + queryKey, + queryFn: query(routes.getUserDetails, { + pathParams: { username }, + }), + enabled: username !== undefined && username !== null, + });
49-53: Consider memoizing the invalidation function.The invalidation function should be memoized to prevent unnecessary re-renders.
- const invalidateUserDetails = () => { - queryClient.invalidateQueries({ - queryKey: ["getUserDetails", username], - }); - }; + const invalidateUserDetails = useCallback(() => { + queryClient.invalidateQueries({ + queryKey: ["getUserDetails", username], + }); + }, [queryClient, username]);src/components/Files/FileBlock.tsx (1)
37-43: Consider adding stale time configuration for the file data.The query looks good, but adding staleTime could optimize refetching behavior for file data that doesn't change frequently.
const { data: fileData } = useQuery({ queryKey: ["file", { id: file.id, type: fileManager.type, associating_id }], queryFn: query(routes.retrieveUpload, { queryParams: { file_type: fileManager.type, associating_id }, pathParams: { id: file.id || "" }, }), - enabled: filetype === "AUDIO" && !file.is_archived, + enabled: filetype === "AUDIO" && !file.is_archived, + staleTime: 5 * 60 * 1000, // 5 minutes });src/components/Files/FileUpload.tsx (2)
123-135: Consider memoizing query invalidation keys.The refetch function could be optimized by memoizing the query keys.
+ const activeQueryKey = useMemo(() => ["viewUpload", "active", type, associatedId], [type, associatedId]); + const archivedQueryKey = useMemo(() => ["viewUpload", "archived", type, associatedId], [type, associatedId]); + const dischargeSummaryQueryKey = useMemo(() => ["viewUpload", "discharge_summary", associatedId], [associatedId]); - const refetchAll = () => { + const refetchAll = useCallback(() => { queryClient.invalidateQueries({ - queryKey: ["viewUpload", "active", type, associatedId], + queryKey: activeQueryKey, }); queryClient.invalidateQueries({ - queryKey: ["viewUpload", "archived", type, associatedId], + queryKey: archivedQueryKey, }); if (type === "consultation") { queryClient.invalidateQueries({ - queryKey: ["viewUpload", "discharge_summary", associatedId], + queryKey: dischargeSummaryQueryKey, }); } - }; + }, [queryClient, activeQueryKey, archivedQueryKey, dischargeSummaryQueryKey, type]);
180-185: Consider simplifying the queries object.The queries object could be simplified using object shorthand notation.
const queries = { - UNARCHIVED: { data: activeFiles, isLoading: activeFilesLoading }, - ARCHIVED: { data: archivedFiles, isLoading: archivedFilesLoading }, - DISCHARGE_SUMMARY: { - data: dischargeSummary, - isLoading: dischargeSummaryLoading, - }, + UNARCHIVED: { data: activeFiles, isLoading: activeFilesLoading }, + ARCHIVED: { data: archivedFiles, isLoading: archivedFilesLoading }, + DISCHARGE_SUMMARY: { data: dischargeSummary, isLoading: dischargeSummaryLoading }, };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/components/Files/FileBlock.tsx(4 hunks)src/components/Files/FileUpload.tsx(4 hunks)src/components/Users/UserHome.tsx(4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: cypress-run (1)
🔇 Additional comments (1)
src/components/Files/FileUpload.tsx (1)
176-176:⚠️ Potential issueNormalize case when checking type for discharge summary query.
Based on past review comments, there's still a case sensitivity issue in the enabled condition.
- enabled: type === "consultation", + enabled: type.toLowerCase() === "consultation",Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/components/Users/UserHome.tsx (2)
40-46: Add error handling to the query implementation.While the query implementation is good, consider handling error states to improve user experience.
- const { data: userData, isLoading } = useQuery({ + const { data: userData, isLoading, error } = useQuery({ queryKey: ["getUserDetails", username], queryFn: query(routes.getUserDetails, { pathParams: { username }, }), enabled: Boolean(username), }); + if (error) { + return <ErrorPage error={error} />; + }
48-50: Separate loading and data availability checks.Consider handling loading and data availability separately for more precise error handling and better debugging.
- if (isLoading || !userData) { + if (isLoading) { return <Loading />; } + + if (!userData) { + return <ErrorPage error="No user data available" />; + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/Users/UserHome.tsx(4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: cypress-run (1)
- GitHub Check: OSSAR-Scan
🔇 Additional comments (2)
src/components/Users/UserHome.tsx (2)
1-1: LGTM! Clean import changes for TanStack Query integration.The imports are correctly updated to support the migration to TanStack Query's
useQueryhook.Also applies to: 16-16
131-131: LGTM! Properly implemented feedback from previous review.The component correctly implements the previous review feedback by removing the refetch prop drilling, aligning with the recommendation to use
invalidateQueriesdirectly where needed.
| <SelectedTab | ||
| userData={userData} | ||
| username={username} | ||
| {...props} | ||
| refetchUserData={refetchUserDetails} | ||
| /> | ||
| <SelectedTab userData={userData} username={username} {...props} /> |
There was a problem hiding this comment.
you should be deleting the prop too from here and update all tabs to not call that anymore and instead use invalidate queries.
There was a problem hiding this comment.
which is this file, is this userColumns?
Part of #9837
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit
Release Notes
Refactor
useQueryhook.useQueryimplementation.Performance
Maintenance