feat(my-pages): Health center changes #16637
Conversation
WalkthroughThe pull request introduces several enhancements to the rights portal's health and nutrition management features. A new enum, Changes
Possibly related PRs
Suggested labels
Suggested reviewers
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
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #16637 +/- ##
==========================================
+ Coverage 35.59% 35.62% +0.02%
==========================================
Files 6920 6915 -5
Lines 146139 145974 -165
Branches 41512 41448 -64
==========================================
- Hits 52021 52005 -16
+ Misses 94118 93969 -149
Flags with carried forward coverage won't be shown. Click here to find out more. see 16 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Datadog ReportBranch report: ✅ 0 Failed, 4 Passed, 0 Skipped, 2.45s Total Time |
disaerna
added
the
deprecated:automerge
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (9)
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.graphql (1)
26-26: Consider adding neighborhoodCenter to nested objectsFor data consistency and completeness, consider whether
neighborhoodCentershould also be included in thecurrentandhistoryobjects, especially if this information can change over time.rightsPortalHealthCenterRegistrationHistory(input: $input) { current { healthCenterName doctor + neighborhoodCenter } history { dateFrom dateTo healthCenterName doctor + neighborhoodCenter } canRegister neighborhoodCenter }libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenterRecordHistory.model.ts (1)
14-16: Consider adding JSDoc documentation for the new field.Adding documentation would help other developers understand the purpose and usage of this field.
@Field({ nullable: true }) +/** The neighborhood health center associated with this registration history */ neighborhoodCenter?: stringlibs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.graphql (1)
12-12: Consider adding field documentation.The new
canRegisterfield aligns well with the PR objectives. Consider adding a description in the GraphQL schema to document its purpose and usage.libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenter.model.ts (1)
22-23: Add documentation for the new fieldThe implementation looks good and follows the established patterns. Consider adding documentation to improve maintainability:
+ /** + * Indicates whether a patient can register with this health center + */ @Field(() => Boolean, { nullable: true, + description: 'Indicates if the health center is accepting new registrations' }) canRegister?: boolean | nulllibs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts (1)
16-19: Consider adding JSDoc documentationSince this is a library function (
libs/**/*), adding JSDoc documentation would improve reusability by making the function's purpose and parameters clear to consumers.Add documentation like this:
+/** + * Generates an AidOrNutrition object from DTO data + * @param data - The data transfer object containing aid/nutrition information + * @param type - The type of the aid/nutrition entry + * @returns An AidOrNutrition object or null if required fields are missing + */ export const generateAidOrNutrition = ( data: AidOrNutritionDTO, type: AidOrNutritionType, ): AidOrNutrition | null => {libs/api/domains/rights-portal/src/lib/healthCenter/healthCenter.service.ts (1)
Line range hint
1-100: Architecture aligns with best practices.The service implementation follows good architectural patterns:
- Located in the libs directory for reusability across NextJS apps
- Framework-agnostic implementation using dependency injection
- Clear separation of concerns with domain-specific models
libs/portals/my-pages/health/src/screens/AidsAndNutrition/Aids.tsx (2)
106-121: Consider refactoring the renewal status display logic.The current chain of ternary operators makes the code harder to maintain. Consider using a mapping object for better readability and maintainability.
const renewalStatusMessages = { [RightsPortalAidOrNutritionRenewalStatus.VALID]: messages.valid, [RightsPortalAidOrNutritionRenewalStatus.VALID_FOR_RENEWAL]: messages.validForRenewal, [RightsPortalAidOrNutritionRenewalStatus.RENEWAL_IN_PROGRESS]: messages.renewalInProgress, [RightsPortalAidOrNutritionRenewalStatus.NOT_VALID_FOR_RENEWAL]: messages.notValidForRenewal, } as const // Then in the render: value: rowItem.renewalStatus ? formatMessage(renewalStatusMessages[rowItem.renewalStatus] ?? '') : ''
Line range hint
1-121: Component follows portal library guidelines.The implementation aligns well with the coding guidelines for library code:
- Uses shared components from @island.is/portals/my-pages/core
- Properly typed with TypeScript interfaces
- Specific imports that support tree-shaking
- Reusable design with clear props interface
libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.tsx (1)
Line range hint
221-227: Consider using Text component props instead of CSS stylesWhile the text visibility improvement is good, consider replacing the CSS-styled strong tag with Text component props for better maintainability and consistency.
<Text variant="medium"> - <strong className={styles.strongStyle}> + <Text as="span" fontWeight="semiBold"> {formatMessage(messages.alert)} - </strong> + </Text> {formatMessage(messages.healthCenterRegistrationWarning)} </Text>
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (14)
libs/api/domains/rights-portal/src/lib/aidOrNutrition/models/aidOrNutrition.model.ts(2 hunks)libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts(3 hunks)libs/api/domains/rights-portal/src/lib/healthCenter/healthCenter.service.ts(1 hunks)libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenter.model.ts(1 hunks)libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenterRecordHistory.model.ts(1 hunks)libs/clients/icelandic-health-insurance/rights-portal/src/clientConfig.json(5 hunks)libs/clients/icelandic-health-insurance/rights-portal/src/index.ts(0 hunks)libs/portals/my-pages/health/src/lib/messages.ts(4 hunks)libs/portals/my-pages/health/src/screens/AidsAndNutrition/Aids.tsx(3 hunks)libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.graphql(1 hunks)libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.tsx(3 hunks)libs/portals/my-pages/health/src/screens/HealthCenter/HistoryTable.tsx(1 hunks)libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.graphql(1 hunks)libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.tsx(4 hunks)
💤 Files with no reviewable changes (1)
- libs/clients/icelandic-health-insurance/rights-portal/src/index.ts
✅ Files skipped from review due to trivial changes (1)
- libs/portals/my-pages/health/src/screens/HealthCenter/HistoryTable.tsx
🧰 Additional context used
📓 Path-based instructions (12)
libs/api/domains/rights-portal/src/lib/aidOrNutrition/models/aidOrNutrition.model.ts (1)
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."
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts (1)
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."
libs/api/domains/rights-portal/src/lib/healthCenter/healthCenter.service.ts (1)
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."
libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenter.model.ts (1)
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."
libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenterRecordHistory.model.ts (1)
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."
libs/clients/icelandic-health-insurance/rights-portal/src/clientConfig.json (1)
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."
libs/portals/my-pages/health/src/lib/messages.ts (1)
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."
libs/portals/my-pages/health/src/screens/AidsAndNutrition/Aids.tsx (1)
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."
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.graphql (1)
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."
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.tsx (1)
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."
libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.graphql (1)
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."
libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.tsx (1)
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."
🔇 Additional comments (22)
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.graphql (1)
26-26: Verify the type of neighborhoodCenter field
The addition of the field aligns with the PR objectives. However, let's verify the type definition in the GraphQL schema.
✅ Verification successful
The neighborhoodCenter field is correctly typed as a nullable string
Based on the search results, I can verify that:
- The field is properly defined in the GraphQL schema as shown in
libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenterRecordHistory.model.ts:@Field({ nullable: true }) neighborhoodCenter?: string
- The client configuration in
libs/clients/icelandic-health-insurance/rights-portal/src/clientConfig.jsonconfirms it:"neighborhoodCenter": { "type": "string", "nullable": true }
- The field is properly used in the UI component with null-coalescing operator in
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.tsx.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find the type definition for rightsPortalHealthCenterRegistrationHistory
# and verify the type of neighborhoodCenter field
# Search for the type definition
rg -A 10 "type.*rightsPortalHealthCenterRegistrationHistory" --type graphql
Length of output: 109
Script:
#!/bin/bash
# Let's try searching for schema files and type definitions using different approaches
# Search for any GraphQL schema files
fd "\.(graphql|gql)$"
# Search for type definitions containing "HealthCenter"
rg "type.*HealthCenter" -A 10
# Search for files containing "neighborhoodCenter"
rg "neighborhoodCenter" -A 5 -B 5
Length of output: 27896
libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenterRecordHistory.model.ts (1)
14-16: LGTM! The new field follows TypeScript and NestJS best practices.
The implementation is type-safe and properly integrated with GraphQL through decorators.
libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.graphql (1)
12-12: Verify GraphQL schema compatibility.
Ensure that the backend GraphQL schema has been updated to support the new canRegister field.
libs/api/domains/rights-portal/src/lib/healthCenter/models/healthCenter.model.ts (1)
22-23: Verify GraphQL schema usage
Let's ensure this field is properly integrated into the GraphQL schema and queries.
✅ Verification successful
Based on the search results, I can see that the canRegister field is properly integrated into the GraphQL schema and is being used in several components:
- It's defined in the model (
healthCenter.model.ts) - It's used in GraphQL queries in multiple files:
HealthCenterRegistration.graphqlHealthCenter.graphql
- It's being used in React components:
HealthCenterRegistration.tsxHealthCenter.tsx
The field is being used for conditional rendering and business logic in the frontend components, and it's properly defined in the GraphQL schema. Let me verify one more aspect of the implementation:
Field is properly integrated in the GraphQL schema and implementation
The canRegister field is correctly integrated into the GraphQL schema and implementation:
-
Properly defined in the model with GraphQL decorators:
@Field(() => Boolean, { nullable: true })inhealthCenter.model.ts- Type defined as
boolean | null
-
Implemented in the service layer:
healthCenter.service.tshandles the field with proper null coalescing- Default value of
falseis set when the field is null
-
Used in GraphQL operations:
- Present in GraphQL queries
- Consumed by frontend components for conditional rendering
-
Type-safe implementation across the stack from model to view layer.
The field follows GraphQL best practices and is properly integrated into the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the usage of canRegister field in GraphQL operations
# Check for GraphQL queries using this field
rg -t graphql "canRegister"
# Check for TypeScript/JavaScript files using this field in queries or mutations
rg "canRegister.*health.*center" -t ts -t js
# Look for test files covering this field
rg -t ts "canRegister.*test"
Length of output: 137
Script:
#!/bin/bash
# Let's try a different approach to find GraphQL and TypeScript usage
# Search for canRegister in all files
rg "canRegister" -A 3 -B 3
# Find all GraphQL schema definitions and operations
fd "\.(graphql|gql)$"
# Look for TypeScript files that might contain GraphQL operations
rg "@(Query|Mutation|Field|ObjectType)" -l | grep "\.ts$"
Length of output: 165918
Script:
#!/bin/bash
# Check for resolver implementation and service usage
rg -A 5 -B 5 "canRegister.*health.*center" -t ts
Length of output: 50
Script:
#!/bin/bash
# Let's check the resolver and service implementation
rg -A 5 -B 5 "canRegister" libs/api/domains/rights-portal/src/lib/healthCenter/
Length of output: 3539
libs/api/domains/rights-portal/src/lib/aidOrNutrition/models/aidOrNutrition.model.ts (2)
2-5: LGTM! Clean import organization.
The imports are well-structured and follow TypeScript best practices.
9-11: LGTM! Proper enum registration.
The enum registration follows the established naming convention and GraphQL patterns.
libs/api/domains/rights-portal/src/lib/healthCenter/healthCenter.service.ts (1)
100-100: LGTM! Verify type definitions for the new field.
The implementation of neighborhoodCenter follows good practices with proper null handling. The nullish coalescing operator ensures type safety.
Let's verify the type definitions are properly updated:
✅ Verification successful
Type definitions and usage are properly implemented
The verification shows that:
- The type definition exists in
models/healthCenterRecordHistory.model.tswith correct optional string type - The field is properly used in the service layer with null coalescing
- The field is correctly consumed in the UI component with proper null handling
The implementation maintains type safety across the stack and follows consistent patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the HealthCenterRegistrationHistory type includes the new field
# and verify its usage across the codebase
# Check the type definition
ast-grep --pattern 'interface HealthCenterRegistrationHistory {
$$$
neighborhoodCenter?: string
$$$
}'
# Check for any usages of the new field
rg -t typescript "neighborhoodCenter" --glob "!*.test.*" --glob "!*.spec.*"
Length of output: 221
Script:
#!/bin/bash
# Let's try different approaches to find type definitions and usages
# Search for interface or type definitions containing neighborhoodCenter
rg -l "neighborhoodCenter.*?:" --type ts
# Search for all occurrences of neighborhoodCenter
rg "neighborhoodCenter" --type ts
# Find all TypeScript files in the health center directory
fd "\.ts$" -p libs/api/domains/rights-portal/src/lib/healthCenter/
# Try to find the interface definition file
fd "types\.ts$|\.interface\.ts$" -p libs/api/domains/rights-portal/src/lib/healthCenter/
Length of output: 1976
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.tsx (2)
50-50: LGTM!
Good use of nullish coalescing operator for the default value. The variable naming is clear and consistent with the codebase.
125-133: LGTM!
The implementation:
- Properly handles conditional rendering
- Reuses the
UserInfoLinecomponent - Uses React fragments appropriately
- Maintains consistent UI with dividers
libs/portals/my-pages/health/src/screens/AidsAndNutrition/Aids.tsx (2)
1-4: LGTM! Import changes follow best practices.
The import of RightsPortalAidOrNutritionRenewalStatus from the shared API schema promotes reusability and maintains proper TypeScript typing.
77-77: LGTM! Table header follows i18n practices.
The new renewal column is properly internationalized using formatMessage.
libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.tsx (3)
12-12: LGTM: Import added correctly
The Tooltip import is properly added to the existing destructured import from the shared UI library.
279-291: LGTM: Consistent header styling improvements
The table headers now have improved visual hierarchy with consistent styling using Text components.
306-316: LGTM: Consistent data cell styling improvements
The table data cells now have improved readability with consistent Text component usage.
libs/portals/my-pages/health/src/lib/messages.ts (4)
90-114: LGTM! Complete set of renewal status messages.
The renewal status messages form a comprehensive set covering all possible states (in progress, valid, not valid) with appropriate detail messages.
238-246: LGTM! Clear user feedback for registration restrictions.
The messages effectively communicate when a health center is not available for registration, with a clear explanation of neighborhood-based restrictions.
649-652: LGTM! Neighborhood health center label added.
The message provides a clear label for the neighborhood health center feature.
337-337: LGTM! More specific health center title.
The title change from "Heilsugæsla" to "Skráð heilsugæsla" better reflects that this refers to the registered health center.
libs/clients/icelandic-health-insurance/rights-portal/src/clientConfig.json (4)
313-352: New endpoint follows REST best practices
The new endpoint /v1/aidsandnutrition/{iso}/renew is well-designed:
- Uses proper HTTP GET method for retrieving renewal status
- Path parameter is properly documented
- Includes comprehensive error responses
4158-4161: LGTM: Health center registration capability flag added
The canRegister boolean field is appropriately added to the HealthCenterDTO schema with nullable property.
2459-2459: Improved flexibility in accident reporting
Good changes to the AccidentDTO schema:
- Removed
dateTimeOfDoctorVisitandsymptomsfrom required fields - Made
dateTimeOfDoctorVisitnullable
This allows for more flexible accident reporting where doctor visit details might not be immediately available.
Also applies to: 2485-2486
2928-2939: Verify enum values documentation
The renewalStatus enum is added to AidOrNutritionDTO with values [0,1,2,3], but the meaning of each value is not documented. This could lead to confusion during implementation.
Consider adding documentation for each enum value using OpenAPI's enum description capabilities:
"Minarsidur.API.Models.AidsAndNutrition.AidOrNutritionDTO_RenewalStatusEnum": {
"enum": [0, 1, 2, 3],
"type": "integer",
- "format": "int32"
+ "format": "int32",
+ "description": "Renewal status values",
+ "enumDescriptions": {
+ "0": "Description for status 0",
+ "1": "Description for status 1",
+ "2": "Description for status 2",
+ "3": "Description for status 3"
+ }
}
libs/api/domains/rights-portal/src/lib/aidOrNutrition/models/aidOrNutrition.model.ts
Show resolved
Hide resolved
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts
Outdated
Show resolved
Hide resolved
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts
Outdated
Show resolved
Hide resolved
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts
Outdated
Show resolved
Hide resolved
libs/portals/my-pages/health/src/screens/HealthCenter/HealthCenter.tsx
Outdated
Show resolved
Hide resolved
libs/portals/my-pages/health/src/screens/AidsAndNutrition/Aids.tsx
Outdated
Show resolved
Hide resolved
libs/portals/my-pages/health/src/screens/HealthCenterRegistration/HealthCenterRegistration.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts (1)
9-14: Simplify enum definitionThe enum values are redundantly set to strings matching their names. TypeScript automatically assigns string values matching the key names when no explicit values are provided.
Apply this diff to simplify the enum:
export enum AidOrNutritionRenewalStatus { - 'VALID' = 'VALID', - 'VALID_FOR_RENEWAL' = 'VALID_FOR_RENEWAL', - 'RENEWAL_IN_PROGRESS' = 'RENEWAL_IN_PROGRESS', - 'NOT_VALID_FOR_RENEWAL' = 'NOT_VALID_FOR_RENEWAL', + VALID, + VALID_FOR_RENEWAL, + RENEWAL_IN_PROGRESS, + NOT_VALID_FOR_RENEWAL }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts (1)
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."
🔇 Additional comments (3)
libs/api/domains/rights-portal/src/lib/aidOrNutrition/utils/generateAidOrNutrition.ts (3)
16-21: LGTM! Clear and type-safe mapping implementation
The constant provides a clear mapping between numeric values and enum cases, with proper type safety through const assertion.
Line range hint 1-62: Meets reusability and TypeScript guidelines
The implementation follows the coding guidelines for libs:
- Proper TypeScript usage with explicit types and enums
- Exports are clearly defined for reuse
- Generic implementation suitable for use across different NextJS apps
Line range hint 23-59: Verify renewalStatus mapping implementation
The implementation looks good with proper type safety and undefined checks. Let's verify that all possible renewalStatus values from the DTO are handled correctly.
✅ Verification successful
Renewal status mapping is correctly implemented
The implementation is verified to be complete and type-safe. The RENEWAL_STATUS_MAP correctly maps all possible enum values:
- VALID (0)
- VALID_FOR_RENEWAL (1)
- RENEWAL_IN_PROGRESS (2)
- NOT_VALID_FOR_RENEWAL (3)
The mapping is consistent with the usage in the codebase, particularly in the Aids component where all these statuses are handled.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all possible renewalStatus values from the DTO are handled
# Search for the DTO definition to check possible values
ast-grep --pattern 'interface AidOrNutritionDTO {
$$$
renewalStatus?: $_
$$$
}'
# Search for any direct usage of renewalStatus to ensure consistent handling
rg -A 2 'renewalStatus'
Length of output: 3107
Script:
#!/bin/bash
# Let's find the RENEWAL_STATUS_MAP and enum definitions to verify the mapping completeness
# Find the RENEWAL_STATUS_MAP definition
ast-grep --pattern 'RENEWAL_STATUS_MAP = {
$$$
}'
# Find the RenewalStatus enum definition
ast-grep --pattern 'enum $_ {
$$$
VALID
$$$
}'
Length of output: 108
Script:
#!/bin/bash
# Let's try different patterns to find the enum and mapping definitions
# Search for renewal status related constants and types
rg -A 10 'RenewalStatus|RENEWAL_STATUS' --type ts
# Search for any enum containing VALID as a value
rg -A 10 'enum.*\{[\s\S]*VALID' --type ts
Length of output: 9583
* feat: add changes to healthCenter WIP * feat: api update * feat: add renewal * fix: font weight and size * fix: PR comments --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
My pages - Health - Health center changes
What
Why
Specify why you need to achieve this
Screenshots / Gifs
Attach Screenshots / Gifs to help reviewers understand the scope of the pull request
Checklist:
Summary by CodeRabbit
New Features
renewalStatusin aid/nutrition entries andneighborhoodCenterin health center registration history.Bug Fixes
Documentation
Style