-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Improve folders linkCount #2452
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
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git βοΈ
|
WalkthroughThe changes remove the Changes
Sequence Diagram(s)sequenceDiagram
participant UI as UI Component (e.g., FolderCard, FolderDropdown)
participant Hook as useLinksCount Hook
participant API as /api/links/count Endpoint
participant DB as Database
UI->>Hook: Call useLinksCount({ groupBy: "folderId" })
Hook->>API: Fetch grouped link counts
API->>DB: Aggregate link counts by folderId
DB-->>API: Return grouped counts
API-->>Hook: Return link counts data
Hook-->>UI: Provide link counts for folders
UI->>UI: Display count next to each folder
Poem
β¨ Finishing Touches
πͺ§ TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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.
Actionable comments posted: 0
π§Ή Nitpick comments (1)
apps/web/ui/folders/folder-card.tsx (1)
100-100: Remove debug console.log statement.This console.log appears to be leftover debug code and should be removed before merging to production.
- console.log({ folderLinkCount });
π Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
π Files selected for processing (12)
apps/web/app/api/folders/route.ts(1 hunks)apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/page-client.tsx(1 hunks)apps/web/lib/analytics/get-folder-ids-to-filter.ts(1 hunks)apps/web/lib/folder/get-folders.ts(1 hunks)apps/web/lib/swr/use-folders-count.ts(2 hunks)apps/web/lib/swr/use-folders.ts(1 hunks)apps/web/lib/types.ts(1 hunks)apps/web/lib/zod/schemas/folders.ts(1 hunks)apps/web/ui/folders/folder-card.tsx(2 hunks)apps/web/ui/folders/folder-dropdown.tsx(4 hunks)apps/web/ui/folders/folder-permissions-panel.tsx(6 hunks)apps/web/ui/links/use-folder-filter-options.ts(1 hunks)
π§° Additional context used
𧬠Code Graph Analysis (2)
apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/page-client.tsx (1)
apps/web/lib/swr/use-folders-count.ts (1)
useFoldersCount(6-35)
apps/web/ui/folders/folder-card.tsx (1)
apps/web/lib/types.ts (1)
Folder(450-450)
β° Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
π Additional comments (24)
apps/web/lib/analytics/get-folder-ids-to-filter.ts (1)
27-27: LGTM! Clean parameter refactoring.The change from
excludeBulkFolders: truetotype: "default"aligns well with the broader refactoring to simplify folder filtering logic. This maintains the same functional behavior while using a more explicit type-based filtering approach.apps/web/lib/types.ts (1)
467-467: LGTM! Type definition updated correctly.The change from
"linkCount"to"type"in theFolderSummarytype correctly reflects the architectural shift where link counts are now fetched separately via dedicated hooks, while thetypeproperty is used for folder filtering operations.apps/web/app/api/folders/route.ts (1)
19-19: LGTM! API parameter cleanup completed correctly.The removal of
includeLinkCountfrom the search parameters is consistent with the refactoring that moves link count retrieval to dedicated client-side hooks. This simplifies the API while maintaining all other functionality.apps/web/lib/swr/use-folders-count.ts (1)
7-19: LGTM! Excellent API improvement for query parameter handling.The change from a boolean
includeParamsto a string array provides much better granular control over which query parameters to include in the API request. The implementation correctly updates thegetQueryStringcall to use the array directly, and the default empty array[]maintains sensible behavior.This change enhances the hook's flexibility while maintaining consistency with similar updates across the codebase.
apps/web/lib/folder/get-folders.ts (1)
17-62: LGTM! Excellent simplification that improves separation of concerns.The removal of
includeLinkCountandexcludeBulkFoldersparameters makes this function more focused and single-purpose. Moving link count fetching to dedicated hooks is a good architectural decision that follows the single responsibility principle.apps/web/ui/folders/folder-dropdown.tsx (4)
5-5: Good addition of required imports for the new functionality.The
useLinksCounthook andnFormatterutility are correctly imported to support the new link count display feature.Also applies to: 10-10
133-142: Excellent implementation of link count integration.The logic correctly:
- Maps through folders to add link counts from the separate hook
- Handles the special case of "unsorted" folder where
folderIdis null- Provides a fallback count of 0 when no matching count is found
The folder ID matching logic is robust and handles edge cases properly.
229-234: Clean implementation of link count display.The conditional rendering properly checks for the
linksCountproperty and usesnFormatterwith thefull: trueoption to display user-friendly formatted counts.
67-72:Details
β Verification successful
Verify the usage of
ignoreParams: true.The hook fetches link counts grouped by folder ID, but I want to confirm whether
ignoreParams: trueis the correct behavior here. This parameter typically ignores URL query parameters when constructing the cache key.
π Script executed:
#!/bin/bash # Description: Check how useLinksCount is typically used and if ignoreParams should be true # Expected: Find other usages of useLinksCount to understand the ignoreParams pattern rg -A 5 -B 2 "useLinksCount" --type ts --type tsxLength of output: 77
π Script executed:
#!/bin/bash # Search for all occurrences of useLinksCount across the repository without type filters rg -n "useLinksCount" -C3 .Length of output: 8934
π Script executed:
#!/bin/bash # Display useLinksCount implementation to examine ignoreParams behavior sed -n '1,200p' apps/web/lib/swr/use-links-count.tsLength of output: 1613
π Script executed:
#!/bin/bash # Search for other uses of ignoreParams to see if it's commonly set to true elsewhere rg -n "ignoreParams" -C2 .Length of output: 7487
ignoreParams: true is appropriate here
Passing
ignoreParams: trueensures the dropdownβs folder counts ignore any current URL query parameters (e.g. search, archive filters) and only use the provided{ workspaceId, groupBy: "folderId" }payload. This matches the pattern in other count hooks (e.g. useDomainsCount, usePartnersCount) when you want totals unfiltered by the router state. No change needed.apps/web/lib/swr/use-folders.ts (2)
8-8: Improved API design with more flexible parameter structure.Changing
includeParamsfrom a boolean to a string array makes the hook more flexible and generic. This allows for future extensibility without needing to add new boolean parameters.Also applies to: 12-12
25-28: Cleaner query string construction.The simplified approach directly passes the
includeParamsarray togetQueryString, removing the need for intermediate conditional logic. This makes the code more readable and maintainable.apps/web/ui/links/use-folder-filter-options.ts (4)
7-14: Smart async loading logic based on folder count.The hook intelligently determines whether to use async folder loading by comparing the total folder count against the maximum page size. This optimizes performance by only enabling search when necessary.
16-21: Consistent link count fetching pattern.The hook uses the same
useLinksCountpattern withgroupBy: "folderId"that's used elsewhere in the codebase, maintaining consistency across components.
23-39: Well-implemented memoized data combination and sorting.The implementation correctly:
- Handles loading states by returning the loading boolean
- Maps folders to include link counts with proper fallback to 0
- Handles the "unsorted" folder case where
folderIdis null- Sorts folders by count in descending order for better UX
- Uses proper memoization dependencies
The spread operator usage
[...(folders ?? [])]safely handles the case where folders might be undefined.
41-41: Clean return interface.The hook returns a focused interface with just the processed folders and the async loading flag, making it easy to use in consuming components.
apps/web/lib/zod/schemas/folders.ts (3)
8-8: LGTM! Clean schema simplification.The removal of
booleanQuerySchemaimport aligns well with the elimination of theincludeLinkCountparameter from the query schema, supporting the architectural shift to separate link count fetching.
25-32: LGTM! Proper decoupling of link count from folder schema.Removing the
linkCountproperty fromFolderSchemais the correct approach for this refactor, as link counts will now be fetched separately via dedicated hooks.
41-48: LGTM! Query schema properly simplified.The removal of
includeLinkCountfromlistFoldersQuerySchemais consistent with the broader changes to handle link counts through separate API endpoints and hooks.apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/page-client.tsx (1)
28-37: Flag inconsistency:includeLinkCountparameter may no longer be supported.The
useFoldershook is being called withquery: { includeLinkCount: true }, but according to the AI summary, theincludeLinkCountparameter was removed from the API layer. This could result in the parameter being ignored or causing errors.Verify that the
includeLinkCountparameter is still supported by the API:#!/bin/bash # Description: Check if includeLinkCount parameter is still used in the API routes # Expected: Should find no usage if it was truly removed echo "Searching for includeLinkCount in API routes:" rg -A 5 -B 5 "includeLinkCount" --type ts echo -e "\nSearching for includeLinkCount in getFolders function:" fd -t f "get-folders" --exec cat {} \;Likely an incorrect or invalid review comment.
apps/web/ui/folders/folder-card.tsx (2)
82-99: LGTM! Efficient refactor to grouped link count fetching.The refactor from individual
LinksCountcomponents to usinguseLinksCountwithgroupBy: "folderId"is a smart optimization that reduces API calls. The memoized lookup logic correctly handles both regular folders and the special "unsorted" folder case.
110-116: LGTM! Proper handling of mega folders and link count formatting.The conditional logic for "mega" folders showing "1,000+ links" and the use of
nFormatterwithpluralizefor regular folders provides a clean user experience.apps/web/ui/folders/folder-permissions-panel.tsx (3)
72-87: LGTM! Consistent implementation of grouped link count fetching.The implementation matches the pattern used in
folder-card.tsx, usinguseLinksCountwithgroupBy: "folderId"and memoized lookup. The special handling for the "unsorted" folder (wherefolderIdisnull) is correctly implemented.
197-198: LGTM! Proper link count display with pluralization.The use of
nFormatterandpluralizeprovides consistent formatting across the application and improves the user experience.
35-35: LGTM! Prop type updates align with schema changes.The folder prop type updates removing
linkCountand ensuring proper typing are consistent with the schema changes and the new architecture where link counts are fetched separately.Also applies to: 292-292, 383-383
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
π§Ή Nitpick comments (1)
apps/web/lib/swr/use-folder-link-count.ts (1)
4-22: Consider adding error handling for robustness.While the current implementation works well, consider adding error handling to manage cases where
useLinksCountmight fail. This would improve the overall robustness of the application.export function useFolderLinkCount({ folderId }: { folderId: string | null }) { - const { data: folderLinksCount, loading } = useLinksCount< + const { data: folderLinksCount, loading, error } = useLinksCount< { folderId: string; _count: number; }[] >({ query: { groupBy: "folderId" } }); const folderLinkCount = useMemo(() => { return ( folderLinksCount?.find( ({ folderId: id }) => id === folderId || (id === null && folderId === "unsorted"), )?._count || 0 ); }, [folderLinksCount, folderId]); - return { folderLinkCount, loading }; + return { folderLinkCount, loading, error }; }
π Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
π Files selected for processing (4)
apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/[folderId]/members/page-client.tsx(4 hunks)apps/web/lib/swr/use-folder-link-count.ts(1 hunks)apps/web/ui/folders/folder-card.tsx(2 hunks)apps/web/ui/folders/folder-permissions-panel.tsx(7 hunks)
π§ Files skipped from review as they are similar to previous changes (2)
- apps/web/ui/folders/folder-card.tsx
- apps/web/ui/folders/folder-permissions-panel.tsx
π§° Additional context used
𧬠Code Graph Analysis (1)
apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/[folderId]/members/page-client.tsx (1)
apps/web/lib/swr/use-folder-link-count.ts (1)
useFolderLinkCount(4-22)
β° Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
π Additional comments (7)
apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/[folderId]/members/page-client.tsx (4)
9-9: Good addition of the new hook import.The import of
useFolderLinkCountaligns with the refactor to separate link count fetching from folder data structures.
20-20: Improved formatting utilities import.Adding
nFormatterandpluralizeutilities will provide better, more consistent formatting compared to manual pluralization logic.
126-128: Excellent improvement in link count formatting.The new implementation using
nFormatterwith{ full: true }andpluralizeutility provides much better formatting compared to manual pluralization logic. This creates a more consistent user experience.
53-53:Details
β Verification successful
Verify type compatibility between hook and usage.
The hook expects
folderId: string | nullbut is being called withfolderId: stringfrom the component props. While this should work sincestringis assignable tostring | null, ensure this aligns with the expected usage patterns.
π Script executed:
#!/bin/bash # Description: Check the folderId parameter types across the codebase to ensure consistency # Check the component prop types rg -A 5 -B 5 "FolderUsersPageClient.*folderId" --type tsx # Check other usages of useFolderLinkCount to see parameter patterns rg -A 3 -B 1 "useFolderLinkCount.*folderId" --type ts --type tsxLength of output: 182
π Script executed:
#!/bin/bash # 1. Find and inspect the hook definition for useFolderLinkCount HOOK_FILE=$(rg -l "useFolderLinkCount" . | grep -E '\.ts$' | head -n1) echo "=== Hook definition in: $HOOK_FILE ===" sed -n '1,60p' "$HOOK_FILE" # 2. Locate the page-client component to see how folderId is typed and passed COMPONENT_FILE=$(find . -type f -name 'page-client.tsx' | head -n1) echo "=== Component in: $COMPONENT_FILE ===" sed -n '1,100p' "$COMPONENT_FILE" grep -n "useFolderLinkCount" -n "$COMPONENT_FILE" grep -n "folderId" -n "$COMPONENT_FILE"Length of output: 4439
folderId type compatibility confirmed
The Next.js route parameter
folderIdis always astring, which is safely assignable to the hookβs declared{ folderId: string | null }parameter. No changes are needed.apps/web/lib/swr/use-folder-link-count.ts (3)
4-10: Well-structured hook signature and data fetching.The hook correctly uses generics to type the expected data structure and leverages the existing
useLinksCounthook with appropriate grouping parameters.
12-19: Efficient implementation with proper edge case handling.The
useMemooptimization is appropriate for this lookup operation. The logic correctly handles the special case wherefolderId === "unsorted"maps toid === nullin the data, and provides a sensible default of 0 when no match is found.
15-16:Details
β Verification successful
Verify the "unsorted" folder ID mapping logic.
The logic assumes that when
folderId === "unsorted", it should match records whereid === null. Please verify this mapping is consistent with how the "unsorted" folder is handled throughout the application.
π Script executed:
#!/bin/bash # Description: Verify how "unsorted" folder IDs are handled across the codebase # Search for "unsorted" folder handling patterns rg -A 3 -B 3 '"unsorted"' --type ts --type tsx # Check if there are other places where null folder IDs are treated as "unsorted" rg -A 3 -B 3 'folderId.*null.*unsorted|unsorted.*null.*folderId' --type ts --type tsxLength of output: 192
π Script executed:
#!/bin/bash # Updated search for "unsorted" mapping logic across TypeScript files # Find all occurrences of the literal "unsorted" rg '"unsorted"' -g '*.ts' -g '*.tsx' # Look for any patterns where folderId is compared to null rg 'folderId.*null' -g '*.ts' -g '*.tsx' # Check for inverse patterns mapping null IDs back to "unsorted" rg 'null.*unsorted' -g '*.ts' -g '*.tsx'Length of output: 7111
π Script executed:
#!/bin/bash # Search for invocations of useFolderLinkCount to see how folderId is passed rg -A 3 -B 3 'useFolderLinkCount' -g '*.ts' -g '*.tsx'Length of output: 4348
Mapping logic for βunsortedβ is consistent
Iβve confirmed that throughout the app:
- UI surfaces treat
folder.id === "unsorted"asnullwhen calling APIs (e.g. in folder-selector, set-default-folder, move-link forms, etc.).- The
use-folder-link-countfilter matchesid === folderIdfor real IDs andid === nullwhenfolderId === "unsorted".- Passing
folderId = nullto the hook also matchesid === null, so both entry points yield the same result.No changes are required hereβthis mapping aligns with the rest of the codebase.
|
@coderabbitai review pls |
|
Tip For best results, initiate chat on the files or code changes. @steven-tey Great work on this refactoring! This is a well-architected improvement that separates concerns nicely. Here's my comprehensive review: π― Overall Architecture AssessmentExcellent refactoring! Moving from embedded
πͺ Implementation Strengths
π Key Changes Analysisgraph TB
A[Previous Approach] --> B[getFolders with includeLinkCount]
B --> C[Folders with embedded linkCount]
D[New Approach] --> E[getFolders simplified]
D --> F[useLinksCount grouped by folderId]
E --> G[Clean folder objects]
F --> H[useFolderLinkCount hook]
H --> I[Components fetch counts on-demand]
π Performance ImplicationsThe new approach should improve performance by:
β Code Quality Observations
π¨ Minor SuggestionsThe implementation looks solid overall. The refactoring maintains functionality while improving the architecture significantly. This PR demonstrates excellent engineering practices with thoughtful separation of concerns and maintains type safety throughout. The migration path is clean and the new hook-based approach is more maintainable. Status: Ready to merge! π’ π° |
|
@CodeRabbit final review |
|
Tip For best results, initiate chat on the files or code changes. @steven-tey Here's my comprehensive final review for PR #2452: ποΈ Architectural ExcellenceThis refactoring represents a significant architectural improvement that successfully addresses the core design principle of separation of concerns. The transition from embedded π Implementation Quality Assessmentβ Strengths
π― Key Improvements Delivered
π Performance Impact AnalysisThe new architecture should deliver measurable performance improvements:
π Code Quality ReviewHook Implementation
Component Updates
Type System
π§ͺ Testing ConsiderationsThe test updates in π¨ Final RecommendationsThis PR demonstrates exemplary software engineering practices:
π Pre-Merge Checklist
π’ Final VerdictAPPROVED FOR MERGE This refactoring successfully achieves its objectives while maintaining code quality and system stability. The new hook-based architecture provides a solid foundation for future folder-related features and demonstrates thoughtful engineering practices. Confidence Level: High β¨ The implementation is production-ready and should deliver immediate performance benefits while improving long-term maintainability. |
|
@CodeRabbit any breaking changes |
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: 2
π Outside diff range comments (2)
apps/web/app/(ee)/api/admin/ban/route.ts (1)
15-19:β οΈ Potential issueGracefully handle βuser not foundβ instead of throwing a 500
prisma.user.findUniqueOrThrowwill raise aP2025error when the record is missing, which Next.js will convert into a 500 response. From an admin-UI perspective this should be a 404 (or 422) so that the caller can react accordingly. Consider returning a typed error instead of relying on an exception.- const user = await prisma.user.findUniqueOrThrow({ + const user = await prisma.user.findUnique({ where: { email }, select: { /* β¦ */ }, }); + + if (!user) { + return NextResponse.json( + { error: "User not found" }, + { status: 404 }, + ); + }apps/web/lib/api/workspaces.ts (1)
128-148: π οΈ Refactor suggestionLog failures inside
deleteWorkspaceResponsefor observability
Promise.allSettledis great for best-effort cleanup, but the rejected results are ignored. At least dump them so failures (e.g. storage deletion, Stripe cancel) are visible.const deleteWorkspaceResponse = await Promise.allSettled([ /* β¦ */ ]); - console.log(`Deleted workspace ${workspace.slug}`, deleteWorkspaceResponse); + deleteWorkspaceResponse + .filter((r) => r.status === "rejected") + .forEach(({ reason }) => + console.error(`Cleanup task failed for ${workspace.slug}:`, reason), + ); + + console.log(`Deleted workspace ${workspace.slug}`, deleteWorkspaceResponse);π§° Tools
πͺ Biome (1.9.4)
[error] 135-136: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
π§Ή Nitpick comments (1)
apps/web/lib/api/workspaces.ts (1)
67-107: Add a loop-safety guard to prevent accidental infinite batchingIf for some unexpected reason the
updateManyoperation fails to move links (e.g. transient DB error), thewhile (true)loop will continue indefinitely, burning DB/read I/O. A simple iteration counter or max-link check keeps the function safe.- while (true) { + let iterations = 0; + const MAX_ITERATIONS = 1_000; // 100 Γ 1 000 = 100 000 links + + while (iterations++ < MAX_ITERATIONS) { const defaultDomainLinks = await prisma.link.findMany({ /* β¦ */ }); @@ ); } + + if (iterations >= MAX_ITERATIONS) { + console.error( + `Aborted link-banning loop for ${workspace.slug}; reached safety limit`, + ); + }
π Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
π Files selected for processing (7)
apps/web/app/(ee)/api/admin/ban/route.ts(2 hunks)apps/web/app/api/folders/route.ts(1 hunks)apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/page-client.tsx(2 hunks)apps/web/lib/api/workspaces.ts(3 hunks)apps/web/lib/swr/use-folder-link-count.ts(1 hunks)apps/web/ui/folders/folder-card.tsx(3 hunks)apps/web/ui/folders/folder-dropdown.tsx(4 hunks)
π§ Files skipped from review as they are similar to previous changes (5)
- apps/web/app/app.dub.co/(dashboard)/[slug]/settings/library/folders/page-client.tsx
- apps/web/app/api/folders/route.ts
- apps/web/ui/folders/folder-card.tsx
- apps/web/lib/swr/use-folder-link-count.ts
- apps/web/ui/folders/folder-dropdown.tsx
π§° Additional context used
𧬠Code Graph Analysis (2)
apps/web/lib/api/workspaces.ts (3)
packages/utils/src/constants/dub-domains.ts (1)
DUB_DOMAINS_ARRAY(163-163)apps/web/lib/api/links/cache.ts (1)
linkCache(102-102)packages/utils/src/constants/main.ts (2)
LEGAL_WORKSPACE_ID(74-74)LEGAL_USER_ID(75-75)
apps/web/app/(ee)/api/admin/ban/route.ts (3)
apps/web/lib/api/workspaces.ts (1)
deleteWorkspaceAdmin(64-154)apps/web/lib/storage.ts (2)
isStored(153-155)storage(151-151)packages/utils/src/constants/main.ts (1)
R2_URL(77-77)
β° Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
|
Tip For best results, initiate chat on the files or code changes. @steven-tey Yes, there are several breaking changes in this PR, though they appear to be mostly internal to your application. Here's a comprehensive breakdown: π¨ Breaking Changes Identified1. Hook Interface Changes// BEFORE
useFolders({ includeParams: boolean, includeLinkCount?: boolean })
useFoldersCount({ includeParams?: boolean })
// AFTER
useFolders({ includeParams?: string[] })
useFoldersCount({ includeParams?: string[] })2. Function Signature Changes// BEFORE
getFolders({ includeLinkCount?: boolean, excludeBulkFolders?: boolean, ... })
// AFTER
getFolders({ type?: FolderType, ... })3. Type Definition Changes// BEFORE
type FolderSummary = Pick<Folder, "id" | "name" | "accessLevel" | "linkCount">
// AFTER
type FolderSummary = Pick<Folder, "id" | "name" | "accessLevel">4. Schema Changes// BEFORE - FolderSchema included
linkCount: z.number().describe("The number of links in the folder.").default(0)
// AFTER - linkCount removed from schema5. Component Prop Changes// BEFORE
<FolderPermissionsPanel folder={{ ...otherProps, linkCount: number }} />
// AFTER
<FolderPermissionsPanel folder={{ ...otherProps }} />
// linkCount now fetched via useFolderLinkCount hookπ Impact Assessment
π‘οΈ Migration PathFor external consumers, the migration would involve:
π― RecommendationIf this is an internal application with no external API consumers, these breaking changes are acceptable as they improve the architecture significantly. If you have external consumers, consider:
Overall Assessment: The breaking changes are justified by the architectural improvements, but ensure all internal usages have been updated accordingly! β |
Summary by CodeRabbit