feat: add skeleton loaders for Organizations and Members Details pages (#2852) #2890
Conversation
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughReplaces spinner loading UIs on member and organization detail pages with full-page skeleton components, registers those skeletons in Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
3-220: Consider adding accessibility attributes for screen reader users.The skeleton component provides visual loading feedback but lacks ARIA attributes to communicate loading state to assistive technologies. Consider wrapping the skeleton in a container with
role="status"andaria-live="polite"oraria-busy="true"to announce the loading state to screen reader users.Apply this diff to improve accessibility:
const OrganizationDetailsPageSkeleton = () => { return ( - <div className="min-h-screen bg-white p-8 text-gray-600 dark:bg-[#212529] dark:text-gray-300"> + <div className="min-h-screen bg-white p-8 text-gray-600 dark:bg-[#212529] dark:text-gray-300" role="status" aria-label="Loading organization details"> <div className="mx-auto max-w-6xl">frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx (1)
4-232: Consider accessibility attributes and consistent iteration patterns.Similar to
OrganizationDetailsPageSkeleton, this component would benefit from accessibility attributes to communicate loading state to screen reader users (e.g.,role="status",aria-label).Additionally, the component uses mixed iteration patterns:
[1, 2, 3, 4].map((i) => ...)in some places andArray.from({ length: 5 }, (_, i) => ...)in others. While both work correctly, using a consistent pattern throughout would improve code maintainability.For accessibility, apply a similar diff as suggested for OrganizationDetailsPageSkeleton:
const MemberDetailsPageSkeleton: React.FC = () => { return ( - <div className="min-h-screen bg-white p-8 text-gray-600 dark:bg-[#212529] dark:text-gray-300"> + <div className="min-h-screen bg-white p-8 text-gray-600 dark:bg-[#212529] dark:text-gray-300" role="status" aria-label="Loading member details"> <div className="mx-auto max-w-6xl">For consistency, consider standardizing on one iteration approach (either array literals for fixed small counts or
Array.fromthroughout).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
frontend/__tests__/unit/pages/OrganizationDetails.test.tsx(1 hunks)frontend/__tests__/unit/pages/UserDetails.test.tsx(3 hunks)frontend/src/app/members/[memberKey]/page.tsx(2 hunks)frontend/src/app/organizations/[organizationKey]/page.tsx(2 hunks)frontend/src/components/SkeletonsBase.tsx(2 hunks)frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx(1 hunks)frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-06-20T16:12:59.256Z
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a safety check that ensures HealthMetrics component is only rendered when healthMetricsData exists and has at least one element: `healthMetricsData && healthMetricsData.length > 0`. This makes accessing data[0] safe within the HealthMetrics component.
Applied to files:
frontend/src/app/members/[memberKey]/page.tsx
📚 Learning: 2025-06-20T16:12:59.256Z
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a length check before rendering HealthMetrics: `healthMetricsData.length > 0`. This ensures that when HealthMetrics is rendered, the data array has at least one element, making accessing data[0] safe within the HealthMetrics component.
Applied to files:
frontend/src/app/members/[memberKey]/page.tsx
📚 Learning: 2025-07-12T17:36:57.255Z
Learnt from: Rajgupta36
Repo: OWASP/Nest PR: 1717
File: frontend/__tests__/unit/pages/createProgram.test.tsx:70-86
Timestamp: 2025-07-12T17:36:57.255Z
Learning: When testing React page components that use mocked form components, validation logic should be tested at the form component level, not the page level. Page-level tests should focus on authentication, role checking, submission handling, and navigation logic.
Applied to files:
frontend/__tests__/unit/pages/OrganizationDetails.test.tsxfrontend/__tests__/unit/pages/UserDetails.test.tsx
📚 Learning: 2025-11-17T16:47:05.578Z
Learnt from: anurag2787
Repo: OWASP/Nest PR: 2671
File: frontend/__tests__/unit/components/MultiSearch.test.tsx:427-427
Timestamp: 2025-11-17T16:47:05.578Z
Learning: In the frontend test files for the OWASP/Nest repository, `expect(true).toBe(true)` no-op assertions may be intentionally added as workarounds when ESLint rule jest/expect-expect doesn't detect expectations inside helper functions or waitFor callbacks. These can be resolved by configuring the ESLint rule's assertFunctionNames option to recognize custom assertion helpers instead of flagging them as redundant.
Applied to files:
frontend/__tests__/unit/pages/UserDetails.test.tsx
🔇 Additional comments (4)
frontend/src/app/members/[memberKey]/page.tsx (1)
28-28: LGTM! Clean integration of skeleton loading state.The import and usage of
MemberDetailsPageSkeletonproperly replaces the loading spinner with a skeleton UI, improving the user experience during data loading.Also applies to: 102-104
frontend/src/app/organizations/[organizationKey]/page.tsx (1)
17-17: LGTM! Consistent skeleton implementation.The skeleton loading state is properly integrated, matching the pattern used in the member details page.
Also applies to: 49-51
frontend/src/components/SkeletonsBase.tsx (1)
5-6: LGTM! Skeleton routing properly extended.The new skeleton components are correctly imported and integrated into the switch statement. The dual mapping of both
'member-details'and'members'toMemberDetailsPageSkeletonappears intentional for handling different route contexts.Also applies to: 72-76
frontend/__tests__/unit/pages/UserDetails.test.tsx (1)
546-555: LGTM! Appropriate test coverage for sponsor block.The test correctly verifies that the sponsor block does not render on the user details page, matching the similar test added to OrganizationDetails.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
frontend/src/app/members/[memberKey]/page.tsx (1)
102-104: Consider adding minimal loading a11y semantics on the skeleton wrapper.
If not already handled insideMemberDetailsPageSkeleton, addingaria-busy="true"(and optionallyrole="status") to the wrapper helps assistive tech.- return <div data-testid="user-loading-skeleton"><MemberDetailsPageSkeleton /></div> + return ( + <div data-testid="user-loading-skeleton" aria-busy="true" role="status"> + <MemberDetailsPageSkeleton /> + </div> + )
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
frontend/__tests__/unit/pages/OrganizationDetails.test.tsx(2 hunks)frontend/__tests__/unit/pages/UserDetails.test.tsx(3 hunks)frontend/src/app/members/[memberKey]/page.tsx(2 hunks)frontend/src/app/organizations/[organizationKey]/page.tsx(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- frontend/src/app/organizations/[organizationKey]/page.tsx
- frontend/tests/unit/pages/UserDetails.test.tsx
- frontend/tests/unit/pages/OrganizationDetails.test.tsx
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-06-20T16:12:59.256Z
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a safety check that ensures HealthMetrics component is only rendered when healthMetricsData exists and has at least one element: `healthMetricsData && healthMetricsData.length > 0`. This makes accessing data[0] safe within the HealthMetrics component.
Applied to files:
frontend/src/app/members/[memberKey]/page.tsx
📚 Learning: 2025-06-20T16:12:59.256Z
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a length check before rendering HealthMetrics: `healthMetricsData.length > 0`. This ensures that when HealthMetrics is rendered, the data array has at least one element, making accessing data[0] safe within the HealthMetrics component.
Applied to files:
frontend/src/app/members/[memberKey]/page.tsx
🔇 Additional comments (1)
frontend/src/app/members/[memberKey]/page.tsx (1)
26-29: Import change looks good; keep skeletons import path consistent with the repo’s pattern.
No concerns with switching fromLoadingSpinnertoMemberDetailsPageSkeletonat the import level.
|
Hi @arkid15r |
kasya
left a comment
kasya
left a comment
There was a problem hiding this comment.
@dhirukumar This looks good (with minor required updates), but I am concerned about this approach in general.
With current approach OrganizationDetailsPageSkeleton (and Members skeleton page as well) hardcodes the layout. If we ever add new components or rearrange the layout we'd also need to remember to update the skeletons to match.
I feel like it makes much more sense to add skeletons for specific components (like RecentReleases, RecentPullRequests, etc.) and render them while loading the page.
This can be handled as all or nothing with a global loading state passed in from the parent component to DetailsCard component or any other component we will work with. 🤔
However, since switching to this new model with separate components skeletons will take awhile to implement (work on adding skeletons for all components, update pages where we use them) - I think it makes sense to still work on this and merge this in for now 👍🏼
I left a couple of requests to address, but overall this looks good ⬇️
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
|
hi @kasya I also agree that implementing this properly will take some time since it would involve creating skeletons for individual components and updating the pages to handle a shared loading state. This actually feels like a good candidate for a larger refactor, potentially something that could be planned as part of GSoC 2026–level work. For now, based on the current requirements and to ensure we make incremental progress, I’ll go ahead and update this PR with the minor changes you mentioned and keep the existing approach so it can be merged. Thank you a lot for the guidance — it really helps shape a better long-term direction for this feature |
Co-authored-by: Kate Golovanova <[email protected]>
Co-authored-by: Kate Golovanova <[email protected]>
…ton.tsx Co-authored-by: Kate Golovanova <[email protected]>
…ton.tsx Co-authored-by: Kate Golovanova <[email protected]>
…ton.tsx Co-authored-by: Kate Golovanova <[email protected]>
Co-authored-by: Kate Golovanova <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
3-6: Consider adding accessibility attributes for screen readers.The skeleton component currently doesn't provide loading state information to assistive technologies. Consider adding attributes like
aria-busy="true"orrole="status"with anaria-labelto the root container to improve accessibility.Example:
const OrganizationDetailsPageSkeleton = () => { return ( - <div className="min-h-screen bg-white p-8 text-gray-600 dark:bg-[#212529] dark:text-gray-300"> + <div + className="min-h-screen bg-white p-8 text-gray-600 dark:bg-[#212529] dark:text-gray-300" + role="status" + aria-busy="true" + aria-label="Loading organization details" + > <div className="mx-auto max-w-6xl">
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx(1 hunks)frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
🔇 Additional comments (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
1-6: LGTM: Clean component structure.The imports and root container setup are appropriate, with proper background and layout styling for a full-page skeleton.
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
4-18: Unresolved: Update ItemCardSkeleton background colors to match actual components.This styling mismatch was previously flagged but remains unaddressed. The
ItemCardSkeletonusesbg-white dark:bg-gray-900(line 5), but according to prior review feedback, it should usebg-gray-200 dark:bg-gray-700to match the actualItemCardListcomponent. This affects the visual consistency of the Issues, Milestones, Pull Requests, and Releases sections during loading.🔎 Apply the previously suggested fix
const ItemCardSkeleton = ({ titleWidth }: { titleWidth: string }) => ( - <div className="mb-4 rounded-lg border-1 border-gray-200 bg-white p-4 shadow-xs dark:border-gray-700 dark:bg-gray-900"> + <div className="mb-4 rounded-lg border-1 border-gray-200 bg-gray-200 p-4 shadow-xs dark:border-gray-700 dark:bg-gray-700"> <Skeleton className={`mb-2 h-5 ${titleWidth}`} /> <div className="mt-2 flex flex-wrap items-center text-sm"> <div className="mr-4 flex items-center">
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx(1 hunks)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (2)
132-144: Verify Releases skeleton matches actual component structure.Per reviewer kasya's unresolved feedback, the Releases section skeleton may still not match the actual loaded
RecentReleasescomponent appearance. While the current implementation uses the sameItemCardSkeletonapproach as other sections, please confirm this accurately represents the real component's structure and styling.Run the following script to examine the actual RecentReleases component structure:
#!/bin/bash # Description: Find and examine the RecentReleases component to verify skeleton matches # Find RecentReleases component file fd -t f "RecentRelease" frontend/src/components # Display the component structure rg -A 30 "const RecentReleases|function RecentReleases|export.*RecentReleases" frontend/src/components --type tsx --type ts
4-18: Address unresolved styling mismatch in ItemCardSkeleton.The ItemCardSkeleton still uses
bg-white dark:bg-gray-900(line 5), but according to previous review feedback, it should usebg-gray-200 dark:bg-gray-700to match the actualItemCardListcomponent used for Issues, Milestones, and Pull Requests. This mismatch causes visual inconsistency during loading states.🔎 Proposed fix
const ItemCardSkeleton = ({ titleWidth }: { titleWidth: string }) => ( - <div className="mb-4 rounded-lg border-1 border-gray-200 bg-white p-4 shadow-xs dark:border-gray-700 dark:bg-gray-900"> + <div className="mb-4 rounded-lg border-1 border-gray-200 bg-gray-200 p-4 shadow-xs dark:border-gray-700 dark:bg-gray-700"> <Skeleton className={`mb-2 h-5 ${titleWidth}`} /> <div className="mt-2 flex flex-wrap items-center text-sm">
🧹 Nitpick comments (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
34-65: Grid layout is responsive and structured well.The 5:2 column split for Organization Details and Statistics provides good visual balance. The skeleton placeholders appropriately represent the content structure.
Note: The hardcoded
min-h-[235px](line 37) could be brittle if the actual component's height changes. Consider deriving heights from the actual component or using more flexible spacing if this becomes a maintenance issue.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-17T02:42:41.928Z
Learnt from: Rajgupta36
Repo: OWASP/Nest PR: 2288
File: frontend/src/components/ActionButton.tsx:0-0
Timestamp: 2025-09-17T02:42:41.928Z
Learning: In frontend/src/components/ActionButton.tsx, the user Rajgupta36 intentionally changed text-blue-600 to text-[#1D7BD7] to align the text color with the border color (#1D7BD7) for visual consistency, prioritizing design alignment over theme tokens.
Applied to files:
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
🔇 Additional comments (3)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (3)
20-33: LGTM: Main skeleton structure is well-organized.The root structure with proper dark mode support and intentional spacing for the description area looks good.
67-86: Top Contributors section has appropriate skeleton structure.The responsive grid with 12 placeholder contributors and consistent card styling matches the expected layout well.
88-115: Issues and Milestones layout structure is appropriate.The two-column grid with reasonable item counts (5 issues, 2 milestones) provides good skeleton representation. Note that visual consistency depends on the ItemCardSkeleton styling fix mentioned in the earlier comment.
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (2)
4-18: ItemCardSkeleton styling still doesn't match the actual ItemCardList component.The card background classes remain inconsistent with the actual component they represent. A previous reviewer identified that ItemCardList uses
bg-gray-200 dark:bg-gray-700, but this skeleton still usesbg-white dark:bg-gray-900(line 5). This creates a visual mismatch when the skeleton transitions to loaded content.🔎 Proposed fix
- <div className="mb-4 rounded-lg border-1 border-gray-200 bg-white p-4 shadow-xs dark:border-gray-700 dark:bg-gray-900"> + <div className="mb-4 rounded-lg border-1 border-gray-200 bg-gray-200 p-4 shadow-xs dark:border-gray-700 dark:bg-gray-700">
131-151: Releases section structure remains unresolved per previous reviewer feedback.A reviewer previously flagged that the Releases skeleton doesn't visually match the actual loaded component, and this concern was reiterated in follow-up comments indicating it "still doesn't look right." The current implementation reuses the generic
SectionSkeletonwithItemCardSkeleton, but the actual RecentReleases component may have a different structure (e.g., release title, tag/version info, metadata row, and action elements) that should be reflected in the skeleton for accurate layout representation.Based on previous reviewer comments, consider creating a dedicated release card skeleton that mirrors the actual RecentReleases component structure, including proper placeholders for release tags, timestamps, and action buttons.
🧹 Nitpick comments (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
57-58: Consider removing the empty spacing div.The empty
<div className="mb-7"></div>is used solely for spacing. While functional, apply margin utilities directly to adjacent elements rather than inserting empty divs for layout control.🔎 Proposed fix
Remove the empty div and apply the margin to the next element:
- {/* Description - empty for organization */} - <div className="mb-7"></div> - {/* Main Grid - Organization Details and Statistics */} - <div className="grid grid-cols-1 gap-6 md:grid-cols-7"> + <div className="mt-7 grid grid-cols-1 gap-6 md:grid-cols-7">
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsxfrontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-17T02:42:41.928Z
Learnt from: Rajgupta36
Repo: OWASP/Nest PR: 2288
File: frontend/src/components/ActionButton.tsx:0-0
Timestamp: 2025-09-17T02:42:41.928Z
Learning: In frontend/src/components/ActionButton.tsx, the user Rajgupta36 intentionally changed text-blue-600 to text-[#1D7BD7] to align the text color with the border color (#1D7BD7) for visual consistency, prioritizing design alignment over theme tokens.
Applied to files:
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Run frontend e2e tests
- GitHub Check: Run backend tests
- GitHub Check: Run frontend unit tests
- GitHub Check: CodeQL (javascript-typescript)
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
frontend/src/components/skeletons/sharedSkeletons.tsx (1)
19-43: Component composition is clean and reusable.The
SectionSkeletoncomponent provides good composability by rendering multipleItemCardSkeletoninstances with proper key generation. The optionalminHeightparameter offers flexibility for different layouts.Optional: Consider constraining minHeight to specific Tailwind classes
For type safety, you could define a union type for
minHeight:type MinHeight = 'min-h-[600px]' | 'min-h-[400px]' | 'min-h-[800px]' | undefinedThis would catch typos at compile time, though the current string approach is more flexible.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsxfrontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsxfrontend/src/components/skeletons/sharedSkeletons.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
🧰 Additional context used
🧬 Code graph analysis (1)
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx (1)
frontend/src/components/skeletons/sharedSkeletons.tsx (1)
SectionSkeleton(19-43)
🔇 Additional comments (1)
frontend/src/components/skeletons/sharedSkeletons.tsx (1)
3-17: LGTM! Card styling matches design requirements.The
ItemCardSkeletoncomponent correctly implements the suggested styling pattern from past reviews, providing consistent card appearance with proper border, shadow, and dark mode support.
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
81-92: Consider addingminHeightto the Releases section for consistency.The Releases section (line 90) is missing a
minHeightproperty, while the Issues, Milestones, and Pull Requests sections all specifymin-h-[600px]. This inconsistency may cause uneven section heights during loading.🔎 Proposed fix
{ keyPrefix: 'pr', titleWidth: 'w-48', itemTitleWidth: 'w-3/4', minHeight: 'min-h-[600px]', }, - { keyPrefix: 'release', titleWidth: 'w-36', itemTitleWidth: 'w-2/3' }, + { + keyPrefix: 'release', + titleWidth: 'w-36', + itemTitleWidth: 'w-2/3', + minHeight: 'min-h-[600px]', + },
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsxfrontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsxfrontend/src/components/skeletons/sharedSkeletons.tsx
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-09-17T02:42:41.928Z
Learnt from: Rajgupta36
Repo: OWASP/Nest PR: 2288
File: frontend/src/components/ActionButton.tsx:0-0
Timestamp: 2025-09-17T02:42:41.928Z
Learning: In frontend/src/components/ActionButton.tsx, the user Rajgupta36 intentionally changed text-blue-600 to text-[#1D7BD7] to align the text color with the border color (#1D7BD7) for visual consistency, prioritizing design alignment over theme tokens.
Applied to files:
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx
📚 Learning: 2025-04-30T13:41:20.846Z
Learnt from: codic-yeeshu
Repo: OWASP/Nest PR: 1444
File: frontend/src/components/NavDropDown.tsx:0-0
Timestamp: 2025-04-30T13:41:20.846Z
Learning: When implementing dropdown menus or similar interactive components, always include proper accessibility features: ARIA attributes (aria-expanded, aria-haspopup, aria-controls), keyboard navigation support (Enter, Space, Escape keys), and mechanisms to close dropdowns when clicking outside.
Applied to files:
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
📚 Learning: 2025-06-21T12:21:32.372Z
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/GradientRadialChart.tsx:67-116
Timestamp: 2025-06-21T12:21:32.372Z
Learning: The react-apexcharts Chart component does not support ARIA attributes like aria-label and role as direct props. To add accessibility attributes to ApexCharts in React, wrap the Chart component in a container div with the appropriate ARIA attributes.
Applied to files:
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx
🧬 Code graph analysis (2)
frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx (1)
frontend/src/components/skeletons/sharedSkeletons.tsx (4)
PageWrapper(46-59)TitleSection(61-71)SectionHeader(97-111)TwoColumnSection(73-95)
frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx (1)
frontend/src/components/skeletons/sharedSkeletons.tsx (5)
PageWrapper(46-59)TitleSection(61-71)CardSection(113-129)SectionHeader(97-111)TwoColumnSection(73-95)
🔇 Additional comments (1)
frontend/src/components/skeletons/sharedSkeletons.tsx (1)
1-129: LGTM! Well-designed shared skeleton components.The shared skeleton components follow React and accessibility best practices:
- ✅ Proper TypeScript typing with explicit prop interfaces
- ✅ Accessibility attributes:
aria-hidden="true"on all Skeleton elements andaria-busyon PageWrapper- ✅ Reusable and composable design enabling consistent skeleton patterns across pages
- ✅ Clean separation of concerns with single-responsibility components
- ✅ Flexible styling through className props and optional parameters
The modular structure makes it easy to maintain skeleton consistency across the Member and Organization detail pages.
|
OWASP#2852) (OWASP#2890) * feat: add skeletons for members and organizations detail pages * chore: address CodeRabbit suggestions in member and organization pages * run pnpm run format check pass * Update frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx Co-authored-by: Kate Golovanova <[email protected]> * Update frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx Co-authored-by: Kate Golovanova <[email protected]> * Update frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx Co-authored-by: Kate Golovanova <[email protected]> * Update frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx Co-authored-by: Kate Golovanova <[email protected]> * Update frontend/src/components/skeletons/OrganizationDetailsPageSkeleton.tsx Co-authored-by: Kate Golovanova <[email protected]> * Update frontend/src/components/skeletons/MemberDetailsPageSkeleton.tsx Co-authored-by: Kate Golovanova <[email protected]> * issue solve * Solve duplicate card structures * Solve bg issue * Solve hight issue * Update code * Address code duplication * Update code * Update code * Fix invalid class name --------- Co-authored-by: Kate Golovanova <[email protected]>
2 participants
Proposed change
Resolves #2852
This PR introduces skeleton loading components for the following pages:
🟦 Organization Details Page( Home ->Organizations ->OWASP)
OrganizationDetailsPageSkeletoncomponent🟩 Member Details Page( Home -> Members ->Björn Kimminich )
MemberDetailsPageSkeletoncomponent🔧 Additional Updates
/organizations/[organizationKey]/page.tsx/members/[memberKey]/page.tsxSkeletonsBase.tsxto support additional height variants used in detail viewsThese changes modernize the loading state experience and align both pages with Nest’s skeleton design standards.
Checklist
make check-testlocally and all tests passed