-
Notifications
You must be signed in to change notification settings - Fork 61
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
feat(web): My pages links for directorate of labour #17353
base: main
Are you sure you want to change the base?
Conversation
WalkthroughThis pull request introduces a new feature for the Directorate of Labour's My Pages, adding support for both Icelandic and English locales. The changes include creating new page components, updating link resolver routes, defining internationalized messages, and adding a unique page identifier. The implementation spans multiple files across the web application, focusing on providing a comprehensive user experience for accessing Directorate of Labour services. Changes
Sequence DiagramsequenceDiagram
participant User
participant LinkResolver
participant PageComponent
participant MyPagesComponent
participant GraphQL
User->>LinkResolver: Request page
LinkResolver->>PageComponent: Resolve route
PageComponent->>GraphQL: Fetch organization data
GraphQL-->>PageComponent: Return data
PageComponent->>MyPagesComponent: Render with data
MyPagesComponent->>User: Display My Pages
Possibly related PRs
Suggested labels
Suggested reviewers
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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
Documentation and Community
|
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
🧹 Nitpick comments (7)
apps/web/pages/en/o/directorate-of-labour/my-pages/index.ts (1)
1-8
: Consider removing the @ts-ignore directive and resolving any type issues directly.Relying on @ts-ignore directives can introduce type safety gaps and potential runtime errors. Removing it or explicitly addressing the underlying type conflicts ensures safer, more maintainable code.
apps/web/pages/s/vinnumalastofnun/minar-sidur/index.ts (1)
1-8
: Remove @ts-ignore directives if possible.Similar to the English version, removing or addressing the @ts-ignore directive directly helps preserve strict typing and prevents regressions.
libs/shared/types/src/lib/api-cms-domain.ts (1)
10-10
: Add a short docstring for the new enum entry.Providing a simple comment on the purpose or usage of the DirectorateOfLabourMyPages enum value helps future maintainers quickly understand its intent.
apps/web/screens/Organization/DirectorateOfLabour/MyPages.strings.ts (1)
1-80
: Centralize images or configure them via environment variables if feasible.Inlined image URLs are fine for a quick setup. However, storing them in a centralized config or using environment variables can reduce duplication and simplify maintenance. Otherwise, the internationalized messages and overall structure look good.
apps/web/screens/Organization/DirectorateOfLabour/MyPages.tsx (3)
1-3
: Use Next.js recommended file naming for pages located inside apps/web/pages
Since this file resides in “screens/Organization/DirectorateOfLabour” but ultimately represents a page, check whether it aligns with Next.js best practices. Typically, pages are placed directly in the "pages" directory. This structure is acceptable if the application is configured to handle custom routes, but ensure consistent organization.
44-48
: Consider explicit fallback for 'customPageData'
Inside the component, 'customPageData' is optional. Consider providing a fallback if data fetching fails (to avoid null/undefined references).
49-54
: Consider extracting repeated parsing logic into a dedicated function
The path manipulation in line 51 could be encapsulated in a helper if used repeatedly.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
libs/cms/src/lib/generated/contentfulTypes.d.ts
is excluded by!**/generated/**
📒 Files selected for processing (7)
.github/CODEOWNERS
(1 hunks)apps/web/hooks/useLinkResolver/useLinkResolver.ts
(1 hunks)apps/web/pages/en/o/directorate-of-labour/my-pages/index.ts
(1 hunks)apps/web/pages/s/vinnumalastofnun/minar-sidur/index.ts
(1 hunks)apps/web/screens/Organization/DirectorateOfLabour/MyPages.strings.ts
(1 hunks)apps/web/screens/Organization/DirectorateOfLabour/MyPages.tsx
(1 hunks)libs/shared/types/src/lib/api-cms-domain.ts
(1 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
libs/shared/types/src/lib/api-cms-domain.ts (2)
Pattern libs/shared/**/*
: "Confirm that the code adheres to the following:
- Cross-application utility functions, types, and constants.
- TypeScript best practices to ensure type safety and reusability.
- Documentation and examples for library consumers."
Pattern libs/**/*
: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
apps/web/pages/en/o/directorate-of-labour/my-pages/index.ts (1)
Pattern apps/**/*
: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/pages/s/vinnumalastofnun/minar-sidur/index.ts (1)
Pattern apps/**/*
: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Organization/DirectorateOfLabour/MyPages.strings.ts (1)
Pattern apps/**/*
: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/hooks/useLinkResolver/useLinkResolver.ts (1)
Pattern apps/**/*
: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Organization/DirectorateOfLabour/MyPages.tsx (1)
Pattern apps/**/*
: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (8)
apps/web/pages/en/o/directorate-of-labour/my-pages/index.ts (1)
10-12
: Great adherence to Next.js best practices.
The default export of this page component and the usage of getServerSideProps with a wrapper method is a clean, standard approach for server-side rendering.
apps/web/pages/s/vinnumalastofnun/minar-sidur/index.ts (1)
10-12
: The SSR approach is consistent.
Exporting both the page component and getServerSideProps ensures a straightforward server-side rendering strategy that aligns with Next.js best practices.
apps/web/screens/Organization/DirectorateOfLabour/MyPages.tsx (4)
39-42
: Type safety looks good
The “MyPagesProps” interface correctly enforces the needed fields. This is a solid approach to guarantee type safety for your component.
86-110
: Excellent modular usage of CategoryCard
Organizing these cards into separate components fosters readability. This is a good design choice!
168-176
: Wrapped export
Using “withMainLayout” and “withCustomPageWrapper” is consistent with your approach, ensuring layout and custom logic are consistently applied.
17-24
: Ensure proper GraphQL schema alignment
Verify that all types from the schema (e.g., OrganizationPage, QueryGetOrganizationPageArgs) match the actual GraphQL endpoint. Any mismatch could cause runtime errors.
✅ Verification successful
Let me verify the GraphQL schema alignment by checking the actual schema definitions and their usage.
Let me try different commands to verify the GraphQL schema.
GraphQL schema types are properly aligned with the codebase
Based on the search results, all the imported types (ContentLanguage
, CustomPageUniqueIdentifier
, GetNamespaceQuery
, OrganizationPage
, Query
, QueryGetNamespaceArgs
, QueryGetOrganizationPageArgs
) are defined in the GraphQL schema and are consistently used throughout the codebase. The types are properly defined in libs/clients/cms/schema.graphql
and are actively used in multiple files, including the file under review.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for GraphQL schema definitions
rg -t graphql "type (ContentLanguage|CustomPageUniqueIdentifier|GetNamespaceQuery|OrganizationPage|Query)" --multiline
# Search for GraphQL query definitions related to these types
rg -t graphql "(getNamespace|getOrganizationPage).*\{" --multiline -A 5
# Check if these types are used consistently across the codebase
rg "QueryGetNamespaceArgs|QueryGetOrganizationPageArgs" -t typescript
Length of output: 365
Script:
#!/bin/bash
# Search for schema files
fd "schema.(ts|js|graphql)"
# Search for GraphQL type definitions in any file
rg "type (ContentLanguage|CustomPageUniqueIdentifier|GetNamespaceQuery|OrganizationPage)"
# Look for query definitions
rg "(getNamespace|getOrganizationPage)\s*(\(.*\))?\s*\{"
# Check type usage
rg "QueryGetNamespaceArgs|QueryGetOrganizationPageArgs"
Length of output: 24548
apps/web/hooks/useLinkResolver/useLinkResolver.ts (1)
110-113
: Route mapping correctness
The new “directorateoflabourmypages” entry correctly provides both Icelandic and English paths. Ensure there are no typos in the is
path (e.g., domain name spelling) and that the paths match your Next.js pages accurately.
✅ Verification successful
Let me verify the route mapping correctness by checking the Next.js pages and related configurations.
Let me check the actual page implementations to verify if these routes are properly set up.
Let me check for any catch-all or dynamic routes that might handle these paths, as well as search for any related components.
Route mapping is correctly implemented
The paths in the directorateoflabourmypages
entry are verified to be correct. The implementation is supported by:
- Matching page files exist:
apps/web/pages/s/vinnumalastofnun/minar-sidur/index.ts
andapps/web/pages/en/o/directorate-of-labour/my-pages/index.ts
- The paths are consistently used in the DirectorateOfLabour component (
apps/web/screens/Organization/DirectorateOfLabour/MyPages.tsx
) - The route structure follows the established pattern for organization pages in both languages
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for files and directories that might contain route configurations or pages
fd -t f "page|route" apps/web/pages
fd -t f "page|route" apps/web/routes
# Search for any references to these specific paths
rg "/s/vinnumalastofnun/minar-sidur|/en/o/directorate-of-labour/my-pages" -A 2 -B 2
# Check for any other occurrences of similar route patterns
rg "/s/vinnumalastofnun|/en/o/directorate-of-labour" -A 2 -B 2
# Look for any Next.js configuration files that might contain route definitions
fd "next.config" .
Length of output: 1827
Script:
#!/bin/bash
# Check for files related to directorate of labour pages
fd -t f "vinnumalastofnun|directorate.*labour" apps/web/pages
# Look for dynamic route handlers that might handle these paths
fd "\[\[\.\.\..*\]\]\.ts" apps/web/pages
# Check the Next.js config for any relevant route configurations
cat apps/web/next.config.js
Length of output: 5961
Script:
#!/bin/bash
# Check for dynamic routes in organization-related paths
fd -t f . "apps/web/pages/s" "apps/web/pages/en/o"
# Look for components or utilities that might handle these routes
rg -g "!*.test.*" -g "!*.spec.*" "vinnumalastofnun" apps/web
rg -g "!*.test.*" -g "!*.spec.*" "directorate.*labour" apps/web
Length of output: 3207
.github/CODEOWNERS (1)
21-21
: Ownership assignment
Assigning @island-is/stefna to “/libs/shared/types/src/lib/api-cms-domain.ts” is consistent with the new functionalities referencing “DirectorateOfLabourMyPages” in that file.
<Stack space={1}> | ||
{webRichText( | ||
customPageData?.content ?? [], | ||
undefined, | ||
activeLocale, | ||
)} | ||
</Stack> |
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.
Check for third-party content sanitization
When rendering rich text via “webRichText,” confirm that all externally fetched content (like HTML from a CMS) is sanitized to prevent XSS.
MyPages.getProps = async ({ apolloClient, locale }) => { | ||
const organizationSlug = | ||
locale === 'en' ? 'directorate-of-labour' : 'vinnumalastofnun' | ||
|
||
const [ |
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.
💡 Codebase verification
Based on the code analysis, I can now provide a final response:
Organization slug handling needs explicit error handling for unsupported locales
The current implementation only handles 'en' with a ternary operator, implicitly defaulting to 'vinnumalastofnun' for all other locales. This could lead to unexpected behavior since:
- There's no explicit error handling for unsupported locales
- The code assumes only two possible values without proper fallback logic
- No type checking or validation is performed on the locale parameter
Suggested fixes:
- Add explicit locale type checking
- Implement proper error handling for unsupported locales
- Consider using a mapping object or switch statement for better maintainability
- Add validation to ensure the locale is one of the supported values
🔗 Analysis chain
Verify translation fallback for 'organizationSlug'
The slug is chosen based on locale. Confirm that other locales besides 'is' and 'en' default properly without errors.
Let me gather information about locale handling and organization slug translations in the codebase.
Let me search for more specific information about locale handling and organization slugs.
Let me search for more specific information about the locale handling in this particular file and its related components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for locale-based organization slug handling
rg -A 5 "locale.*directorate-of-labour|vinnumalastofnun" --type typescript
# Look for default locale handling
ast-grep --pattern 'locale === $_ ? $_ : $_'
# Search for organization slug related type definitions or interfaces
rg "organizationSlug.*type|interface.*organizationSlug" --type typescript
# Look for any error handling around organization slugs
rg "organizationSlug.*error|catch.*organizationSlug" --type typescript
Length of output: 38006
Script:
#!/bin/bash
# Search for organization slug related code with ripgrep
rg -g "*.{ts,tsx}" "organizationSlug.*=.*locale"
# Search for any error handling or fallback for organization slugs
rg -g "*.{ts,tsx}" "organizationSlug.*\?"
# Look for any locale constants or default locale handling
rg -g "*.{ts,tsx}" "defaultLocale|fallbackLocale"
# Search for organization slug related tests
rg -g "*.{test,spec}.{ts,tsx}" "organizationSlug"
Length of output: 3943
Script:
#!/bin/bash
# Search for the specific file and its imports
rg -g "*.{ts,tsx}" -A 5 -B 5 "MyPages\.getProps"
# Look for any error handling related to locale in the same directory
rg -g "*.{ts,tsx}" "try.*catch.*locale|error.*locale" "./apps/web/screens/Organization/DirectorateOfLabour/"
# Search for any tests related to this component
rg -g "*.test.{ts,tsx}" "MyPages" "./apps/web/screens/Organization/DirectorateOfLabour/"
# Look for other instances of similar organization slug handling
rg -g "*.{ts,tsx}" "locale.*\?.*directorate-of-labour"
Length of output: 1325
My pages links for directorate of labour (Vinnumálastofnun)
Custom page for logins related to the directorate of labour
Screenshots / Gifs
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Documentation