-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditionaly renders pagination component if number of entries is more than results per page #9004
base: develop
Are you sure you want to change the base?
Conditionaly renders pagination component if number of entries is more than results per page #9004
Conversation
❌ Deploy Preview for care-ohc failed.
|
WalkthroughThe changes made in the Changes
Assessment against linked issues
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead let's update the logic in the Pagination component instead that way this behaviour is common for all usages.
care_fe/src/components/Common/Pagination.tsx
Lines 70 to 73 in 6b57124
const totalCount = data.totalCount; | |
if (!totalCount) { | |
return null; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
src/components/Facility/FacilityStaffList.tsx (2)
122-129
: LGTM! Consider extracting the condition for better readability.The conditional rendering logic correctly implements the requirement to show pagination only when needed. The implementation is type-safe with proper null handling.
Consider extracting the condition to a semantic variable name:
+ const shouldShowPagination = (doctorsList?.count ?? 0) > resultsPerPage; - {(doctorsList?.count ?? 0) > resultsPerPage && ( + {shouldShowPagination && ( <Pagination cPage={qParams.page} defaultPerPage={resultsPerPage} data={{ totalCount: doctorsList?.count ?? 0 }} onChange={(page) => updatePage(page)} /> )}
122-129
: Consider memoizing the Pagination component to optimize performance.Since the Pagination component's props only depend on a few values (page, resultsPerPage, count), you could optimize re-renders by memoizing it.
Here's how you could implement this:
const MemoizedPagination = useMemo( () => ( <Pagination cPage={qParams.page} defaultPerPage={resultsPerPage} data={{ totalCount: doctorsList?.count ?? 0 }} onChange={(page) => updatePage(page)} /> ), [qParams.page, resultsPerPage, doctorsList?.count, updatePage] ); // Then in your JSX: {(doctorsList?.count ?? 0) > resultsPerPage && MemoizedPagination}
src/components/Common/Pagination.tsx
Outdated
@@ -68,7 +68,7 @@ const Pagination = ({ | |||
}; | |||
|
|||
const totalCount = data.totalCount; | |||
if (!totalCount) { | |||
if (!totalCount || totalCount < defaultPerPage) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this be the right solution? correct me if I am wrong
if (!totalCount || totalCount < defaultPerPage) { | |
if (!totalCount || totalCount < rowsPerPage) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, apologies updated the logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
src/components/Common/Pagination.tsx (2)
Line range hint
6-12
: Consider simplifying the component props interface.The
data
prop currently only containstotalCount
, which could be directly passed as a prop for better clarity and type safety.Consider this improvement:
interface PaginationProps { - data: { totalCount: number }; + totalCount: number; onChange: (page: number, rowsPerPage: number) => void; defaultPerPage: number; cPage: number; className?: string; }Then update the component usage:
-const totalCount = data.totalCount; +const totalCount = props.totalCount;
Line range hint
19-20
: Optimize state initialization to prevent unnecessary renders.The
rowsPerPage
state is initialized to 3 but immediately overridden bydefaultPerPage
in theuseAbortableEffect
. Consider initializing it with thedefaultPerPage
value directly.- const [rowsPerPage, setRowsPerPage] = useState(3); + const [rowsPerPage, setRowsPerPage] = useState(defaultPerPage);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
src/components/Common/Pagination.tsx
(1 hunks)
🔇 Additional comments (1)
src/components/Common/Pagination.tsx (1)
71-73
: LGTM! The pagination visibility logic is now correct.
The updated condition !totalCount || totalCount < rowsPerPage
properly handles all cases:
- Hides pagination when there are no items
- Hides pagination when items fit in a single page
- Correctly handles the edge case when total items exactly equal rows per page
Let's verify the component behavior with different scenarios:
✅ Verification successful
Let me analyze the usage patterns to verify the pagination behavior. I'll search for any test files and check the component's implementation details.
Based on the analysis of the codebase, I can now provide a final response regarding the pagination visibility change:
The pagination visibility logic is correctly implemented and consistent with the codebase's requirements.
The verification confirms:
- The default page sizes across the codebase range from 6 to 36 items (PER_PAGE_LIMIT: 6, RESULTS_PER_PAGE_LIMIT: 14, PAGINATION_LIMIT: 36)
- Multiple components consistently check if
totalCount > PAGINATION_LIMIT
before rendering pagination - The condition
!totalCount || totalCount < rowsPerPage
properly handles all cases:- Zero items (
!totalCount
) - Items fitting in a single page (
totalCount < rowsPerPage
) - Edge case when total equals page size (correctly hidden)
- Zero items (
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for test cases or usage patterns of the Pagination component
# to ensure the new condition works as expected in all scenarios.
# Test: Look for test files related to Pagination
fd -e test.tsx -e test.ts -e spec.tsx -e spec.ts Pagination
# Test: Search for Pagination component usage to verify prop patterns
rg -A 3 "<Pagination"
Length of output: 9560
Script:
#!/bin/bash
# Look for default page sizes and pagination limits across the codebase
rg "PAGINATION_LIMIT|PER_PAGE_LIMIT|RESULTS_PER_PAGE|rowsPerPage" -A 2
# Search for Pagination component's implementation details
ast-grep --pattern 'const Pagination = $_' -l typescript
Length of output: 17392
…es/8992/staff-capacity-section-pagination-issue
Hi @nihal467 |
…es/8992/staff-capacity-section-pagination-issue
Added logic which makes sure, if number of entries for staff capacity is less than or equal to results per page of that section, only then pagination component is shown, otherwise not
Screenshots
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit