chore(accident-notification): organize utils #17250
Conversation
WalkthroughThis pull request introduces a comprehensive refactoring of the accident notification template, focusing on improving code organization, type safety, and utility function management. The changes span multiple files across the application, with a primary emphasis on restructuring imports, consolidating utility functions, and enhancing type definitions. Key modifications include moving utility functions to more specific modules, updating type definitions, and streamlining component prop structures. Changes
Suggested Labels
Suggested Reviewers
Possibly Related PRs
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
|
jonnigs
changed the title
Datadog ReportAll test runs ✅ 10 Total Test Services: 0 Failed, 10 Passed Test ServicesThis report shows up to 10 services
🔻 Code Coverage Decreases vs Default Branch (4) |
jonnigs
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 comments (7)
libs/application/templates/accident-notification/src/fields/ProxyDocument/index.tsx (1)
Line range hint
14-21: Move document URL to configurationThe hardcoded document URL should be moved to a configuration file for better maintainability and reusability across environments.
+import { PROXY_DOCUMENT_URL } from '../../constants' <Button variant="text"> <a - href={ - 'https://assets.ctfassets.net/8k0h54kbe6bj/1iPv7b9rJhuEyihQ9NlSTk/6fa1595e12237ea54b923c0693de9ef8/umbo___vegna_tilkynningar_slys.docx' - } + href={PROXY_DOCUMENT_URL} target="_blank" rel="noopener noreferrer" >libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/childInCustodySubSection.ts (1)
Line range hint
33-33: Add type safety to condition callbackThe condition callback should have proper type annotations for the answers parameter.
- condition: (answers) => isReportingOnBehalfOfChild(answers), + condition: (answers: AccidentNotification) => isReportingOnBehalfOfChild(answers),libs/application/templates/accident-notification/src/fields/DateOfAccident/index.tsx (2)
Line range hint
41-54: Improve error handling in useEffectThe current error handling only logs to console, which might miss critical failures in production. Consider implementing proper error handling and user feedback.
useEffect(() => { if (dateOfAccident !== undefined) { getIsHealhInsuredCallback({ date: dateOfAccident }) .then((res) => { setValue( 'accidentDetails.isHealthInsured', res?.healthInsuranceIsHealthInsured ? YES : NO, ) }) .catch((err) => { - console.log( - 'An error occured fetching health insurance status: ', - err, - ) + // Handle error appropriately + setValue('accidentDetails.isHealthInsured', NO) + // Notify user about the error + console.error('Failed to fetch health insurance status:', err) }) + return () => { + // Cleanup any pending requests if component unmounts + } } }, [dateOfAccident, getIsHealhInsuredCallback, setValue])
Line range hint
82-103: Simplify form control implementationThe current implementation using a hidden Input wrapped in Controller is unnecessarily complex. Consider simplifying this to use direct form control.
- <Box hidden> - <Controller - name="reason" - defaultValue={application.answers.residenceChangeReason} - render={({ field: { onChange } }) => { - return ( - <Input - {...register('accidentDetails.isHealthInsured', { - onChange: (e) => { - onChange(e.target.value) - setValue('accidentDetails.isHealthInsured', e.target.value) - }, - })} - defaultValue={'yes'} - value={isHealthInsured} - /> - ) - }} - /> - </Box> + <input + type="hidden" + {...register('accidentDetails.isHealthInsured')} + value={isHealthInsured} + />libs/application/templates/accident-notification/src/fields/ApplicationStatus/index.tsx (1)
Line range hint
67-106: Optimize status change detection logic.The current implementation has repetitive code for checking status changes. Consider using a more maintainable approach.
const hasAccidentStatusChanged = useCallback( ( newAccidentStatus: AccidentNotificationStatus, currentAccidentStatus: AccidentNotificationStatus, ) => { if (!currentAccidentStatus) { return true } - if ( - newAccidentStatus.receivedAttachments?.InjuryCertificate !== - currentAccidentStatus.receivedAttachments?.InjuryCertificate - ) { - return true - } - if ( - newAccidentStatus.receivedAttachments?.PoliceReport !== - currentAccidentStatus.receivedAttachments?.PoliceReport - ) { - return true - } - if ( - newAccidentStatus.receivedAttachments?.ProxyDocument !== - currentAccidentStatus.receivedAttachments?.ProxyDocument - ) { - return true - } - if ( - newAccidentStatus.receivedConfirmations?.CompanyParty !== - currentAccidentStatus.receivedConfirmations?.CompanyParty - ) { - return true - } - if ( - newAccidentStatus.receivedConfirmations?.InjuredOrRepresentativeParty !== - currentAccidentStatus.receivedConfirmations?.InjuredOrRepresentativeParty - ) { - return true - } - if (newAccidentStatus.status !== currentAccidentStatus.status) { - return true - } - return false + const attachmentKeys = ['InjuryCertificate', 'PoliceReport', 'ProxyDocument'] as const + const confirmationKeys = ['CompanyParty', 'InjuredOrRepresentativeParty'] as const + + return ( + attachmentKeys.some( + key => + newAccidentStatus.receivedAttachments?.[key] !== + currentAccidentStatus.receivedAttachments?.[key] + ) || + confirmationKeys.some( + key => + newAccidentStatus.receivedConfirmations?.[key] !== + currentAccidentStatus.receivedConfirmations?.[key] + ) || + newAccidentStatus.status !== currentAccidentStatus.status + ) }, [], )libs/application/templates/accident-notification/src/lib/dataSchema.ts (1)
Line range hint
15-18: Fix indentation in conditional blocksThe indentation in the elif and else blocks is inconsistent with Python's syntax requirements.
Apply this fix:
elif loyalty_years >= 3: - discount = 0.1 + discount = 0.1 else: - discount = 0 + discount = 0libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/fishingCompanyInfoSubSection.ts (1)
Line range hint
89-124: Reduce duplication in representative fields configurationThe representative fields share common properties and conditions. Consider extracting these into a configuration object or helper function to improve maintainability and reduce duplication.
Example refactor:
const createRepresentativeField = (config: { id: string; title: string; variant?: string; format?: string; required?: boolean; }) => buildTextField({ ...config, backgroundColor: 'blue', width: 'half', maxLength: 100, condition: (formValue) => !isInjuredAndRepresentativeOfCompanyOrInstitute(formValue), }) // Usage in children array: createRepresentativeField({ id: 'representative.name', title: representativeInfo.labels.name, required: true, }), // ... other fields
🧹 Nitpick comments (29)
libs/application/templates/accident-notification/src/utils/getOptions.ts (2)
11-42: Consider enhancing type safety and functional approach.While the function works correctly, we can improve it by:
- Adding explicit return type
- Using a more functional approach for array construction
Consider this refactor:
-export const getAccidentTypeOptions = (answers: FormValue) => { +export const getAccidentTypeOptions = (answers: FormValue): Array<{ + value: AccidentTypeEnum; + label: string; +}> => { - const options = [ + const baseOptions = [ { value: AccidentTypeEnum.WORK, label: accidentType.labels.work, }, // ... other options ] - if ( + const shouldIncludeHomeActivities = !( !isReportingOnBehalfOfEmployee(answers) && !isReportingOnBehalfOfChild(answers) - ) { - options.unshift({ + ) + + const homeActivitiesOption = { value: AccidentTypeEnum.HOMEACTIVITIES, label: accidentType.labels.homeActivities, - }) - } + } - return options + return shouldIncludeHomeActivities + ? [homeActivitiesOption, ...baseOptions] + : baseOptions }
44-72: Add explicit type definitions for option constants.The constants are well-structured but would benefit from explicit type definitions to improve type safety and documentation.
Consider this enhancement:
+type NotificationOption = { + value: WhoIsTheNotificationForEnum; + label: string; +}; -export const whoIsTheNotificationForOptions = [ +export const whoIsTheNotificationForOptions: NotificationOption[] = [ // ... options ] -export const whoIsTheNotificationForProcureOptions = [ +export const whoIsTheNotificationForProcureOptions: NotificationOption[] = [ // ... options ]libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/rescueSquadInfoSubSection.ts (2)
Line range hint
14-24: Consider enhancing type safety for form valuesWhile the builder functions provide good type safety, the form value types in condition callbacks could be more explicit. Consider defining an interface for the form values to improve type safety and maintainability.
interface RescueSquadFormValues { companyInfo: { name: string; nationalRegistrationId: string; }; representative?: { name: string; nationalId: string; email: string; phoneNumber?: string; }; } export const rescueSquadInfoSubSection = buildSubSection({ id: 'rescueSquadInfo.subSection', title: rescueSquadInfo.general.title, condition: (formValue: RescueSquadFormValues) => isRescueWorkAccident(formValue) && !isReportingOnBehalfOfEmployee(formValue), // ... })
Line range hint
25-94: Consider enhancing component configurabilityThe form fields use hardcoded values for styling (
backgroundColor: 'blue') and validation (maxLength: 100). Consider extracting these configurations to make the component more reusable across different contexts.interface RescueSquadConfig { backgroundColor?: string; maxLength?: number; // other configurable properties } export const rescueSquadInfoSubSection = (config: RescueSquadConfig = {}) => buildSubSection({ // ... children: [ buildMultiField({ // ... children: [ buildTextField({ id: 'companyInfo.name', title: rescueSquadInfo.labels.name, backgroundColor: config.backgroundColor ?? 'blue', maxLength: config.maxLength ?? 100, // ... }), // Apply similar changes to other fields ], }), ], })libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/whoIsTheNotificationForMultiField.ts (1)
3-6: Consider adding explicit type imports for better type safety.While the import path change looks good, consider importing and using explicit types for the options to enhance type safety and documentation.
import { buildMultiField, buildRadioField } from '@island.is/application/core' import { whoIsTheNotificationFor } from '../../../lib/messages' +import type { NotificationOption } from '../../../types' import { whoIsTheNotificationForOptions, whoIsTheNotificationForProcureOptions, } from '../../../utils/getOptions'libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/sportsClubInfoSubSection.ts (1)
Line range hint
52-57: Consider implementing conditional field requirementsThe comment indicates a need for conditional field requirements. Consider implementing this to improve form validation.
Would you like me to help implement conditional field requirements using the form builder's validation capabilities?
libs/application/templates/accident-notification/src/forms/InReviewForm/addAttachmentsSection.ts (1)
Line range hint
21-156: Consider enhancing type definitions for better type safety.The implementation follows good practices for reusability and modularity. To further improve type safety, consider:
- Explicitly typing the section configuration object
- Adding type definitions for the condition callbacks
Example enhancement:
type AttachmentSectionConfig = { condition?: (formValue: FormValue) => boolean; // ... other configuration properties } export const addAttachmentsSection = (isAssignee?: boolean): Section => { // ... existing implementation }libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workAccidentSubSection.ts (1)
Line range hint
58-67: Consider combining agriculture-related logic.The agriculture warning alert is well-implemented, but consider extracting the agriculture-specific configuration into a dedicated constant or helper to improve maintainability.
+const AGRICULTURE_WARNING_CONFIG = { + id: 'attachments.injuryCertificate.alert2', + title: attachments.labels.alertMessage, + description: accidentType.warning.agricultureAccidentWarning, + message: accidentType.warning.agricultureAccidentWarning, + alertType: 'warning' as const, + marginBottom: 5, +}; buildAlertMessageField({ - id: 'attachments.injuryCertificate.alert2', - title: attachments.labels.alertMessage, - description: accidentType.warning.agricultureAccidentWarning, doesNotRequireAnswer: true, - message: accidentType.warning.agricultureAccidentWarning, - alertType: 'warning', condition: (formValue) => isAgricultureAccident(formValue), - marginBottom: 5, + ...AGRICULTURE_WARNING_CONFIG, }),libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/schoolInfoSubSection.ts (2)
Line range hint
15-102: Consider extracting repeated conditions into a utility function.The condition
!isInjuredAndRepresentativeOfCompanyOrInstitute(formValue)is used multiple times. Consider extracting it to improve maintainability.+import { shouldShowRepresentativeFields } from '../../../utils/formUtils' + // School information if school accident export const schoolInfoSubSection = buildSubSection({ // ... other config children: [ buildMultiField({ children: [ // ... other fields buildDescriptionField({ // ... other config - condition: (formValue) => - !isInjuredAndRepresentativeOfCompanyOrInstitute(formValue), + condition: shouldShowRepresentativeFields, }), buildTextField({ // ... other config - condition: (formValue) => - !isInjuredAndRepresentativeOfCompanyOrInstitute(formValue), + condition: shouldShowRepresentativeFields, }), // ... apply to other fields with the same condition ], }), ], })
Line range hint
54-102: Consider implementing conditional field requirements.The comment "Should look into if we can require conditionally" suggests a potential enhancement for form validation.
Would you like me to help implement conditional field requirements for the representative fields? This could improve form validation by making fields required only when they should be visible.
libs/application/templates/accident-notification/src/utils/documentUtils.ts (2)
50-85: Refactor similar functions to reduce code duplicationThe functions
hasReceivedInjuryCertificateOrAddedToAnswers,hasReceivedProxyDocumentOrAddedToAnswers, andhasReceivedPoliceReportOrAddedToAnswersshare similar logic. Consider refactoring them into a single generic function to enhance maintainability and reduce code duplication.Example implementation:
export const hasReceivedDocumentOrAddedToAnswers = ( answers: FormValue, receivedCheck: (answers: FormValue) => boolean, attachmentPath: string ): boolean => { const attachmentFile = getValueViaPath<Array<FileType>>( answers, attachmentPath, [{ key: '', name: '' }], ) return receivedCheck(answers) || hasAttachment(attachmentFile) }And then refactor the specific functions:
export const hasReceivedInjuryCertificateOrAddedToAnswers = (answers: FormValue) => { return hasReceivedDocumentOrAddedToAnswers( answers, hasReceivedInjuryCertificate, 'attachments.injuryCertificateFile.file' ) }
155-203: Consolidate missing document checksThe functions
hasMissingInjuryCertificate,hasMissingDeathCertificate, andhasMissingPowerOfAttorneyFileperform similar checks for missing documents. Consider unifying these into a single generic function to improve code clarity and reduce redundancy.libs/application/templates/accident-notification/src/fields/HiddenInformation/index.tsx (2)
6-12: Enhance Props type definitionThe Props type could be more specific and self-documenting.
-type Props = { +type HiddenInformationProps = { field: { props: { - id: string + /** Unique identifier for the field */ + id: string, + /** Additional field configuration */ + config?: Record<string, unknown> } } }
Line range hint
14-33: Extract hidden inputs to a separate componentConsider extracting the hidden inputs into a reusable component to improve maintainability and reduce complexity.
+const HiddenFields = ({ id, register }: { id: string, register: UseFormRegister<any> }) => ( + <> + <input type="hidden" {...register(`${id}.name`, { required: true })} /> + <input type="hidden" {...register(`${id}.email`, { required: true })} /> + </> +) -export const HiddenInformation = ({ +export const HiddenInformation = ({ application, field, -}: Props & FieldBaseProps) => { +}: HiddenInformationProps & FieldBaseProps) => { // ... existing code ... return !isInjuredAndRepresentativeOfCompanyOrInstitute( application.answers, ) ? null : ( - <> - <input type="hidden" {...register(`${id}.name`, { required: true })} /> - <input type="hidden" {...register(`${id}.email`, { required: true })} /> - </> + <HiddenFields id={id} register={register} /> ) }libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/childInCustodySubSection.ts (1)
Line range hint
19-24: Extract field constraints to constantsConsider extracting magic numbers and formats to named constants for better maintainability.
+const FIELD_CONSTRAINTS = { + NAME_MAX_LENGTH: 100, + NATIONAL_ID_FORMAT: '######-####' +} as const; buildTextField({ id: 'childInCustody.name', backgroundColor: 'blue', title: childInCustody.labels.name, width: 'half', required: true, - maxLength: 100, + maxLength: FIELD_CONSTRAINTS.NAME_MAX_LENGTH, }), buildTextField({ id: 'childInCustody.nationalId', backgroundColor: 'blue', title: childInCustody.labels.nationalId, - format: '######-####', + format: FIELD_CONSTRAINTS.NATIONAL_ID_FORMAT, width: 'half', required: true, }),libs/application/templates/accident-notification/src/utils/accidentUtils.ts (1)
37-52: Consider handling undefined values in getInjuredPersonInformationThe function should handle cases where email or name might be undefined from getValueViaPath.
Consider adding type safety:
export const getInjuredPersonInformation = (answers: FormValue) => { const injuredPersonsEmail = getValueViaPath<string>( answers, 'injuredPersonInformation.email', ) const injuredPersonsName = getValueViaPath<string>( answers, 'injuredPersonInformation.name', ) return { - email: injuredPersonsEmail, - name: injuredPersonsName, + email: injuredPersonsEmail ?? '', + name: injuredPersonsName ?? '', } }libs/application/templates/accident-notification/src/fields/ApplicationStatus/StatusStep/index.tsx (2)
6-14: Strengthen type definitions for ActionPropsThe ActionProps type could be more strict to ensure better type safety.
export type ActionProps = { title: string description: string - fileNames?: string + fileNames?: string[] // Array of filenames is more flexible actionButtonTitle: string hasActionButtonIcon?: boolean showAlways?: boolean - cta?: () => void + cta?: () => Promise<void> // Support async operations }
Line range hint
36-39: Improve callback handlingThe current callback implementation could be more robust with proper type checking.
- const handleOnCTAButtonClick = () => { - action?.cta && action.cta() - } + const handleOnCTAButtonClick = async () => { + try { + if (action?.cta) { + await action.cta() + } + } catch (error) { + console.error('Action failed:', error) + } + }libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/accidentDetailSubSection.ts (1)
Line range hint
67-77: Consider extracting magic numbers to constantsThe maxLength and rows values should be extracted to constants for better maintainability.
+const TEXTAREA_CONFIG = { + MAX_LENGTH: 2000, + ROWS: 10, +} as const; + buildTextField({ id: 'accidentDetails.descriptionOfAccident', title: accidentDetails.labels.description, placeholder: accidentDetails.placeholder.description, backgroundColor: 'blue', required: true, - rows: 10, + rows: TEXTAREA_CONFIG.ROWS, variant: 'textarea', - maxLength: 2000, + maxLength: TEXTAREA_CONFIG.MAX_LENGTH, }),libs/application/templates/accident-notification/src/fields/FormOverviewInReview/index.tsx (1)
12-19: Props type definition could be more comprehensiveWhile the Props type is concise, it could be more explicit about all the expected props. Consider including all required props in the type definition for better type safety.
type Props = { field: { props: { isAssignee: boolean } } + application: { + answers: Record<string, unknown> + } + refetch: () => void + goToScreen?: (screen: string) => void }libs/application/templates/accident-notification/src/utils/accidentUtils.spec.ts (1)
99-137: Consider adding edge cases to getInjuredPersonInformation testsWhile the basic cases are covered, consider adding tests for:
- Malformed input objects
- Missing injuredPersonInformation object
- Special characters in email/name
+ it('Should handle missing injuredPersonInformation object', () => { + expect(getInjuredPersonInformation({})).toEqual({ email: '', name: '' }) + }) + + it('Should handle special characters in name and email', () => { + const specialChars: FormValue = { + injuredPersonInformation: { + email: '[email protected]', + name: 'Jón Dóe', + }, + } + const result = getInjuredPersonInformation(specialChars) + expect(result?.email).toEqual('[email protected]') + expect(result?.name).toEqual('Jón Dóe') + })libs/application/templates/accident-notification/src/types/index.ts (1)
71-74: Consider following TypeScript enum conventions and adding documentation.The enum values should be UPPERCASE following TypeScript conventions, and JSDoc comments would improve maintainability.
+/** Represents yes/no choices throughout the application */ export enum YesOrNo { - YES = 'yes', - NO = 'no', + YES = 'YES', + NO = 'NO', }libs/application/templates/accident-notification/src/fields/ApplicationStatus/applicationStatusUtils.ts (1)
1-21: Improve import organization and add type documentation.Consider grouping related imports and adding JSDoc documentation for the Steps type.
+// External dependencies import { FormatMessage, FormValue, TagVariant, } from '@island.is/application/types' +import { MessageDescriptor } from 'react-intl' + +// Internal dependencies import { inReview } from '../../lib/messages' import { AccidentNotificationStatusEnum } from './StatusStep/types' -import { getValueViaPath } from '@island.is/application/core' import { ReviewApprovalEnum } from '../../types' import { AccidentNotificationStatus } from '@island.is/api/schema' +import { getValueViaPath } from '@island.is/application/core' + +// Utils import { hasReceivedConfirmation, isInjuredAndRepresentativeOfCompanyOrInstitute, shouldRequestReview, } from '../../utils/miscUtils' - import { AccidentNotificationAnswers } from '../..' -import { MessageDescriptor } from 'react-intl' import { ActionProps } from './StatusStep' import { hasReceivedAllDocuments } from '../../utils/documentUtils'libs/application/templates/accident-notification/src/lib/messages/externalData.ts (1)
15-32: Consider removing content duplication in messagesThe content of
bulletOne,bulletTwo, andbulletThreeis duplicated in thebulletsmessage. This duplication could lead to maintenance issues if the content needs to be updated.Consider either:
- Using the individual bullet messages to construct the combined message
- Having a single source of truth and deriving the individual messages from it
Also applies to: 44-46
libs/application/templates/accident-notification/src/utils/documentUtils.spec.ts (3)
22-30: Consider adding edge cases to strengthen test coverage.While the basic scenarios are covered, consider adding test cases for:
- Empty/undefined document lists
- Partial document submissions
57-80: Consider adding error case scenarios.While the happy path scenarios are well covered, consider adding test cases for:
- Invalid/malformed input data
- Edge cases where document status is undefined
82-140: Consider enhancing type safety of test data helpers.The helper functions could benefit from explicit return types:
-const getMissingDocuments = (): FormValue => ({ +const getMissingDocuments = (): AccidentNotification => ({libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/fishingCompanyInfoSubSection.ts (2)
8-8: Consider using path aliases instead of relative pathsWhile the utility organization is improved, the deep relative paths (
../../../utils/) could make the code harder to maintain. Consider using TypeScript path aliases (e.g.,@utils/) to improve maintainability and make imports more resilient to file moves.Also applies to: 10-11
Line range hint
15-21: Extract complex conditions into descriptive helper functionsThe subsection's title and condition logic could be more readable if extracted into helper functions with descriptive names. This would improve maintainability and make the code's intent clearer.
Example refactor:
const getSubSectionTitle = (answers: Application['answers']) => isReportingOnBehalfOfEmployee(answers) ? fishingCompanyInfo.general.informationAboutShipTitle : fishingCompanyInfo.general.title export const fishingCompanyInfoSubSection = buildSubSection({ id: 'fishingCompanyInfo.subSection', title: getSubSectionTitle, condition: isFishermanAccident, // ... })
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (82)
libs/application/templates/accident-notification/src/fields/ApplicationStatus/StatusStep/index.tsx(1 hunks)libs/application/templates/accident-notification/src/fields/ApplicationStatus/StatusStep/types.ts(0 hunks)libs/application/templates/accident-notification/src/fields/ApplicationStatus/applicationStatusUtils.ts(1 hunks)libs/application/templates/accident-notification/src/fields/ApplicationStatus/index.tsx(1 hunks)libs/application/templates/accident-notification/src/fields/DateOfAccident/index.tsx(1 hunks)libs/application/templates/accident-notification/src/fields/FormOverview/ValueLine.tsx(2 hunks)libs/application/templates/accident-notification/src/fields/FormOverview/index.tsx(3 hunks)libs/application/templates/accident-notification/src/fields/FormOverviewInReview/ConfirmationModal.tsx(4 hunks)libs/application/templates/accident-notification/src/fields/FormOverviewInReview/index.tsx(1 hunks)libs/application/templates/accident-notification/src/fields/HiddenInformation/index.tsx(1 hunks)libs/application/templates/accident-notification/src/fields/ProxyDocument/index.tsx(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/accidentDetailSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/accidentTypeSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/attachmentsSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/companyInfoSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/fishingCompanyInfoSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/locationSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/rescueSquadInfoSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/schoolInfoSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/sportsClubInfoSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/studiesAccidentSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workAccidentSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workMachineSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/applicantInformationSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/childInCustodySubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/injuredPersonInformationSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/juridicialPersonCompanySubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/powerOfAttorneySubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/powerOfAttorneyUploadSubSection.ts(1 hunks)libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/whoIsTheNotificationForMultiField.ts(1 hunks)libs/application/templates/accident-notification/src/forms/InReviewForm/addAttachmentsSection.ts(1 hunks)libs/application/templates/accident-notification/src/index.ts(1 hunks)libs/application/templates/accident-notification/src/lib/dataSchema.ts(5 hunks)libs/application/templates/accident-notification/src/lib/messages/externalData.ts(1 hunks)libs/application/templates/accident-notification/src/types/index.ts(3 hunks)libs/application/templates/accident-notification/src/utils/accidentNotificationUtils.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/accidentUtils.spec.ts(1 hunks)libs/application/templates/accident-notification/src/utils/accidentUtils.ts(1 hunks)libs/application/templates/accident-notification/src/utils/constants/index.ts(0 hunks)libs/application/templates/accident-notification/src/utils/dateUtils.spec.ts(2 hunks)libs/application/templates/accident-notification/src/utils/dateUtils.ts(1 hunks)libs/application/templates/accident-notification/src/utils/documentUtils.spec.ts(1 hunks)libs/application/templates/accident-notification/src/utils/documentUtils.ts(1 hunks)libs/application/templates/accident-notification/src/utils/fishermanUtils.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/fishermanUtils.ts(0 hunks)libs/application/templates/accident-notification/src/utils/getAccidentTypeOptions.ts(0 hunks)libs/application/templates/accident-notification/src/utils/getInjuredPersonInformation.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/getInjuredPersonInformation.ts(0 hunks)libs/application/templates/accident-notification/src/utils/getOptions.ts(1 hunks)libs/application/templates/accident-notification/src/utils/getWhoIstheNotificationForOptions.ts(0 hunks)libs/application/templates/accident-notification/src/utils/getWorkplaceData.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/getWorkplaceData.ts(0 hunks)libs/application/templates/accident-notification/src/utils/hasMissingDocuments.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/hasMissingDocuments.ts(0 hunks)libs/application/templates/accident-notification/src/utils/hasReceivedConfirmation.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/hasReceivedConfirmation.ts(0 hunks)libs/application/templates/accident-notification/src/utils/hideLocationAndPurpose.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/hideLocationAndPurpose.ts(0 hunks)libs/application/templates/accident-notification/src/utils/index.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/index.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isAgricultureAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isAgricultureAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isFatalAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isFatalAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isGeneralWorkplaceAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isGeneralWorkplaceAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isHealthInsured.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isHealthInsured.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isHomeActivitiesAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isHomeActivitiesAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isInternshipStudiesAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isInternshipStudiesAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isMachineRelatedAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isMachineRelatedAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isOfWorkTypeAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isPowerOfAttorney.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isPowerOfAttorney.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isProfessionalAthleteAccident.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isProfessionalAthleteAccident.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isReportingBehalfOfSelf.spec.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isReportingBehalfOfSelf.ts(0 hunks)libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfChild.spec.ts(0 hunks)
⛔ Files not processed due to max files limit (27)
- libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfChild.ts
- libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfEmployee.spec.ts
- libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfEmployee.ts
- libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfInjured.spec.ts
- libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfInjured.ts
- libs/application/templates/accident-notification/src/utils/isRepresentativeOfCompanyOrInstitute.spec.ts
- libs/application/templates/accident-notification/src/utils/isRepresentativeOfCompanyOrInstitute.ts
- libs/application/templates/accident-notification/src/utils/isRescueWorkAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isRescueWorkAccident.ts
- libs/application/templates/accident-notification/src/utils/isSportAccidentAndEmployee.spec.ts
- libs/application/templates/accident-notification/src/utils/isSportAccidentAndEmployee.ts
- libs/application/templates/accident-notification/src/utils/isStudiesAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isStudiesAccident.ts
- libs/application/templates/accident-notification/src/utils/isUniqueAssignee.spec.ts
- libs/application/templates/accident-notification/src/utils/isUniqueAssignee.ts
- libs/application/templates/accident-notification/src/utils/isUploadNow.spec.ts
- libs/application/templates/accident-notification/src/utils/isUploadNow.ts
- libs/application/templates/accident-notification/src/utils/isWorkAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isWorkAccident.ts
- libs/application/templates/accident-notification/src/utils/miscUtils.spec.ts
- libs/application/templates/accident-notification/src/utils/miscUtils.ts
- libs/application/templates/accident-notification/src/utils/occupationUtils.spec.ts
- libs/application/templates/accident-notification/src/utils/occupationUtils.ts
- libs/application/templates/accident-notification/src/utils/reportingUtils.spec.ts
- libs/application/templates/accident-notification/src/utils/reportingUtils.ts
- libs/application/templates/accident-notification/src/utils/shouldRequestReview.spec.ts
- libs/application/templates/accident-notification/src/utils/shouldRequestReview.ts
💤 Files with no reviewable changes (41)
- libs/application/templates/accident-notification/src/utils/hideLocationAndPurpose.spec.ts
- libs/application/templates/accident-notification/src/utils/isFatalAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isFatalAccident.ts
- libs/application/templates/accident-notification/src/utils/constants/index.ts
- libs/application/templates/accident-notification/src/utils/isAgricultureAccident.ts
- libs/application/templates/accident-notification/src/utils/isHomeActivitiesAccident.ts
- libs/application/templates/accident-notification/src/utils/accidentNotificationUtils.spec.ts
- libs/application/templates/accident-notification/src/utils/isInternshipStudiesAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isReportingBehalfOfSelf.ts
- libs/application/templates/accident-notification/src/utils/isPowerOfAttorney.ts
- libs/application/templates/accident-notification/src/utils/isInternshipStudiesAccident.ts
- libs/application/templates/accident-notification/src/utils/getAccidentTypeOptions.ts
- libs/application/templates/accident-notification/src/utils/hasMissingDocuments.spec.ts
- libs/application/templates/accident-notification/src/utils/isHomeActivitiesAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isHealthInsured.ts
- libs/application/templates/accident-notification/src/utils/isGeneralWorkplaceAccident.ts
- libs/application/templates/accident-notification/src/utils/isGeneralWorkplaceAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isOfWorkTypeAccident.ts
- libs/application/templates/accident-notification/src/utils/isPowerOfAttorney.spec.ts
- libs/application/templates/accident-notification/src/utils/hideLocationAndPurpose.ts
- libs/application/templates/accident-notification/src/utils/getInjuredPersonInformation.spec.ts
- libs/application/templates/accident-notification/src/utils/getWorkplaceData.spec.ts
- libs/application/templates/accident-notification/src/utils/index.spec.ts
- libs/application/templates/accident-notification/src/utils/isReportingOnBehalfOfChild.spec.ts
- libs/application/templates/accident-notification/src/fields/ApplicationStatus/StatusStep/types.ts
- libs/application/templates/accident-notification/src/utils/getWorkplaceData.ts
- libs/application/templates/accident-notification/src/utils/hasReceivedConfirmation.spec.ts
- libs/application/templates/accident-notification/src/utils/getInjuredPersonInformation.ts
- libs/application/templates/accident-notification/src/utils/isMachineRelatedAccident.ts
- libs/application/templates/accident-notification/src/utils/isAgricultureAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/isHealthInsured.spec.ts
- libs/application/templates/accident-notification/src/utils/isProfessionalAthleteAccident.ts
- libs/application/templates/accident-notification/src/utils/hasReceivedConfirmation.ts
- libs/application/templates/accident-notification/src/utils/isReportingBehalfOfSelf.spec.ts
- libs/application/templates/accident-notification/src/utils/isProfessionalAthleteAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/fishermanUtils.spec.ts
- libs/application/templates/accident-notification/src/utils/isMachineRelatedAccident.spec.ts
- libs/application/templates/accident-notification/src/utils/getWhoIstheNotificationForOptions.ts
- libs/application/templates/accident-notification/src/utils/fishermanUtils.ts
- libs/application/templates/accident-notification/src/utils/index.ts
- libs/application/templates/accident-notification/src/utils/hasMissingDocuments.ts
✅ Files skipped from review due to trivial changes (3)
- libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/powerOfAttorneySubSection.ts
- libs/application/templates/accident-notification/src/index.ts
- libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/accidentTypeSubSection.ts
🧰 Additional context used
📓 Path-based instructions (38)
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/applicantInformationSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/powerOfAttorneyUploadSubSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/injuredPersonInformationSubSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/whoIsTheNotificationForMultiField.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/childInCustodySubSection.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/application/templates/accident-notification/src/fields/FormOverviewInReview/index.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/schoolInfoSubSection.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/application/templates/accident-notification/src/forms/InReviewForm/addAttachmentsSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/studiesAccidentSubSection.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/application/templates/accident-notification/src/fields/FormOverviewInReview/ConfirmationModal.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/application/templates/accident-notification/src/types/index.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/accidentDetailSubSection.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/application/templates/accident-notification/src/lib/dataSchema.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/juridicialPersonCompanySubSection.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/application/templates/accident-notification/src/fields/FormOverview/index.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/application/templates/accident-notification/src/lib/messages/externalData.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/application/templates/accident-notification/src/utils/getOptions.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/application/templates/accident-notification/src/utils/dateUtils.spec.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/application/templates/accident-notification/src/utils/accidentUtils.spec.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workAccidentSubSection.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/application/templates/accident-notification/src/fields/HiddenInformation/index.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/application/templates/accident-notification/src/utils/documentUtils.spec.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/application/templates/accident-notification/src/fields/ApplicationStatus/index.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/application/templates/accident-notification/src/utils/dateUtils.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/application/templates/accident-notification/src/fields/ProxyDocument/index.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/sportsClubInfoSubSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/locationSubSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/rescueSquadInfoSubSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workMachineSubSection.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/application/templates/accident-notification/src/utils/accidentUtils.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/application/templates/accident-notification/src/fields/FormOverview/ValueLine.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/attachmentsSubSection.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/fishingCompanyInfoSubSection.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/application/templates/accident-notification/src/fields/ApplicationStatus/applicationStatusUtils.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/application/templates/accident-notification/src/fields/DateOfAccident/index.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/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/companyInfoSubSection.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/application/templates/accident-notification/src/fields/ApplicationStatus/StatusStep/index.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/application/templates/accident-notification/src/utils/documentUtils.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 (40)
libs/application/templates/accident-notification/src/utils/getOptions.ts (1)
1-9: LGTM! Well-organized imports.
The imports are properly structured with clear separation between types, messages, and utility functions. They support effective tree-shaking as required by the coding guidelines.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/rescueSquadInfoSubSection.ts (1)
9-11: LGTM! Import organization improves code maintainability
The reorganization of utility imports into specific modules (miscUtils, accidentUtils, reportingUtils) enhances code maintainability and follows good practices for module organization. The specific imports also enable effective tree-shaking.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/whoIsTheNotificationForMultiField.ts (1)
Line range hint 8-35: Verify the imported options are available in the new location.
The form field configuration looks good, but let's verify that the options are correctly exported from the new location.
✅ Verification successful
Options are correctly exported and imported in the new location
Both whoIsTheNotificationForOptions and whoIsTheNotificationForProcureOptions are properly exported from utils/getOptions.ts and correctly imported in the form file. The implementation is consistent with the usage in the form configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the options are correctly exported from the new location
# and that there are no other files still importing from the old location.
# Check if the options are exported from the new location
ast-grep --pattern 'export const whoIsTheNotificationForOptions'
# Check for any remaining imports from the old location
rg "from.*getWhoIstheNotificationForOptions"
Length of output: 1999
Script:
#!/bin/bash
# Let's also check for whoIsTheNotificationForProcureOptions which is used in the code
ast-grep --pattern 'export const whoIsTheNotificationForProcureOptions'
# Let's verify the imports in the form file
rg -A 2 "whoIsTheNotificationForOptions|whoIsTheNotificationForProcureOptions" "libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/whoIsTheNotificationForMultiField.ts"
Length of output: 1639
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/sportsClubInfoSubSection.ts (3)
Line range hint 14-24: LGTM! Well-structured and reusable form section
The implementation effectively uses the builder pattern and follows consistent form structure patterns, making it reusable across different NextJS applications.
Line range hint 1-7: LGTM! Effective type safety and tree-shaking
The implementation:
- Uses strongly-typed builder functions from @island.is/application/core
- Has specific imports that enable effective tree-shaking
- Follows TypeScript best practices
8-11: Verify utility file organization and dependencies
The reorganization of utility functions into specific modules (miscUtils, occupationUtils, reportingUtils) improves code organization. However, let's ensure there are no circular dependencies and that the utilities are properly categorized.
✅ Verification successful
The results show that each utility function is properly organized in its respective file with clear, focused implementations:
isInjuredAndRepresentativeOfCompanyOrInstituteinmiscUtils.tsisProfessionalAthleteAccidentinoccupationUtils.tsisReportingOnBehalfOfEmployeeinreportingUtils.ts
Let me verify if there are any dependencies between these utility files:
Utility organization is well-structured and dependency-free
The utility functions have been properly organized into separate, focused files without circular dependencies:
- Each utility function has a clear, single responsibility
- Functions are placed in semantically appropriate files
- No cross-imports between utility files, indicating clean separation
- Implementation details show proper type safety and clear business logic
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential circular dependencies and verify utility organization
# Check for circular imports
rg -l "import.*from.*utils/(miscUtils|occupationUtils|reportingUtils)" libs/application/templates/accident-notification/src/utils/ | while read -r file; do
echo "=== Checking imports in $file ==="
rg "import.*from.*utils/" "$file"
done
# Verify utility categorization
echo "=== Utility function implementations ==="
rg -A 5 "^export (function |const )(isInjuredAndRepresentativeOfCompanyOrInstitute|isProfessionalAthleteAccident|isReportingOnBehalfOfEmployee)"
Length of output: 2479
Script:
#!/bin/bash
# Check imports between utility files
echo "=== Checking miscUtils.ts imports ==="
rg "import.*from.*utils/" libs/application/templates/accident-notification/src/utils/miscUtils.ts
echo -e "\n=== Checking occupationUtils.ts imports ==="
rg "import.*from.*utils/" libs/application/templates/accident-notification/src/utils/occupationUtils.ts
echo -e "\n=== Checking reportingUtils.ts imports ==="
rg "import.*from.*utils/" libs/application/templates/accident-notification/src/utils/reportingUtils.ts
Length of output: 599
libs/application/templates/accident-notification/src/forms/InReviewForm/addAttachmentsSection.ts (1)
16-19: LGTM! Improved module organization.
The reorganization of utility functions into specific modules (documentUtils, miscUtils, reportingUtils, accidentUtils) improves code organization and maintainability.
Let's verify that these utility functions are properly exported from their new locations:
✅ Verification successful
✅ All utility functions are properly exported from their respective modules
The verification confirms that all imported functions are correctly exported from their new locations:
isPowerOfAttorneyandisUniqueAssigneeinmiscUtils.tsisReportingOnBehalfOfInjuredinreportingUtils.tsisFatalAccidentinaccidentUtils.ts
The reorganization successfully maintains the required exports while improving code organization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify utility function exports
# Check for utility function exports
for util in documentUtils miscUtils reportingUtils accidentUtils; do
echo "Checking exports in $util:"
rg -A 1 "export.*{.*}|export function" "utils/$util.ts"
done
Length of output: 1310
Script:
#!/bin/bash
# Let's fix the regex and check for exports in these utility files
# Search for exports in each utility file
echo "Checking documentUtils exports:"
rg "export" "src/utils/documentUtils.ts"
echo -e "\nChecking miscUtils exports:"
rg "export" "src/utils/miscUtils.ts"
echo -e "\nChecking reportingUtils exports:"
rg "export" "src/utils/reportingUtils.ts"
echo -e "\nChecking accidentUtils exports:"
rg "export" "src/utils/accidentUtils.ts"
# Let's also verify if these files exist
echo -e "\nVerifying file existence:"
fd -t f "(documentUtils|miscUtils|reportingUtils|accidentUtils).ts$" src/utils/
Length of output: 968
Script:
#!/bin/bash
# Let's check the correct path structure by finding the utils directory first
echo "Finding utils directory:"
fd -t d "utils$"
# Then search for these utility files in any utils directory
echo -e "\nSearching for utility files:"
fd -t f "(documentUtils|miscUtils|reportingUtils|accidentUtils).ts$"
# Let's also check the imports from the original file to see the correct path
echo -e "\nChecking import paths from the original file:"
rg "import.*from.*utils" "libs/application/templates/accident-notification/src/forms/InReviewForm/addAttachmentsSection.ts"
Length of output: 7717
Script:
#!/bin/bash
# Now that we found the correct files, let's check their exports
echo "Checking documentUtils exports:"
rg "export" "libs/application/templates/accident-notification/src/utils/documentUtils.ts"
echo -e "\nChecking miscUtils exports:"
rg "export" "libs/application/templates/accident-notification/src/utils/miscUtils.ts"
echo -e "\nChecking reportingUtils exports:"
rg "export" "libs/application/templates/accident-notification/src/utils/reportingUtils.ts"
echo -e "\nChecking accidentUtils exports:"
rg "export" "libs/application/templates/accident-notification/src/utils/accidentUtils.ts"
# Specifically check for the imported functions
echo -e "\nChecking for specific function exports:"
rg "export.*(isPowerOfAttorney|isUniqueAssignee|isReportingOnBehalfOfInjured|isFatalAccident)" "libs/application/templates/accident-notification/src/utils/"
Length of output: 3650
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workAccidentSubSection.ts (2)
Line range hint 19-85: LGTM! Well-structured form implementation with proper TypeScript usage.
The code demonstrates good practices:
- Proper use of TypeScript with enum typing
- Reusable form structure using the builder pattern
- Type-safe props through builder functions
15-17: Verify utility imports exist and are properly exported.
The reorganization of utility functions into specific files (accidentUtils, occupationUtils, reportingUtils) improves modularity and tree-shaking. Let's verify these files are properly set up.
✅ Verification successful
All utility imports are correctly organized and exported
The verification confirms that:
- All three utility files exist in the expected location
- Each utility function is properly exported and implemented:
isWorkAccidentinaccidentUtils.tsisAgricultureAccidentinoccupationUtils.tsisReportingOnBehalfSelfinreportingUtils.ts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify utility files exist and export the required functions
# Check if the utility files exist and contain the required exports
for util in "accidentUtils" "occupationUtils" "reportingUtils"; do
echo "Checking $util..."
# Search for the file
fd "$util.ts"
# Search for the exports
case $util in
"accidentUtils")
ast-grep --pattern 'export const isWorkAccident = $_'
;;
"occupationUtils")
ast-grep --pattern 'export const isAgricultureAccident = $_'
;;
"reportingUtils")
ast-grep --pattern 'export const isReportingOnBehalfSelf = $_'
;;
esac
done
Length of output: 3617
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/schoolInfoSubSection.ts (1)
9-12: LGTM! The import reorganization improves modularity.
The separation of utility functions into specific modules enhances code organization and tree-shaking capabilities.
Let's verify the consistency of utility function usage across the codebase:
✅ Verification successful
Import reorganization is correctly implemented and consistent across the codebase
The verification shows that:
- All utility functions are imported from their respective new utility files (
accidentUtils,occupationUtils,reportingUtils, andmiscUtils) - The imports are used consistently across multiple components in the accident-notification template
- No old import patterns were found, indicating a complete migration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the utility functions are imported consistently across the codebase
# Check for any remaining imports from the old utility file structure
rg -l "from.*utils[\"'].*\b(isStudiesAccident|isInternshipStudiesAccident|isReportingOnBehalfOfEmployee|isInjuredAndRepresentativeOfCompanyOrInstitute)\b"
# Check the new import pattern usage
echo "Checking accidentUtils usage:"
rg "from.*utils/accidentUtils.*isStudiesAccident"
echo "Checking occupationUtils usage:"
rg "from.*utils/occupationUtils.*isInternshipStudiesAccident"
echo "Checking reportingUtils usage:"
rg "from.*utils/reportingUtils.*isReportingOnBehalfOfEmployee"
echo "Checking miscUtils usage:"
rg "from.*utils/miscUtils.*isInjuredAndRepresentativeOfCompanyOrInstitute"
Length of output: 690
Script:
#!/bin/bash
# Let's try a different approach to verify the utility functions
# First, let's find these utility files
echo "Searching for utility files:"
fd "utils\.(ts|js)$"
# Then, let's check the function definitions
echo -e "\nChecking function definitions:"
ast-grep --pattern 'export function isStudiesAccident'
ast-grep --pattern 'export function isInternshipStudiesAccident'
ast-grep --pattern 'export function isReportingOnBehalfOfEmployee'
ast-grep --pattern 'export function isInjuredAndRepresentativeOfCompanyOrInstitute'
# Let's also check for any imports of these functions with more lenient patterns
echo -e "\nChecking imports with more lenient patterns:"
rg "import.*isStudiesAccident" -A 1
rg "import.*isInternshipStudiesAccident" -A 1
rg "import.*isReportingOnBehalfOfEmployee" -A 1
rg "import.*isInjuredAndRepresentativeOfCompanyOrInstitute" -A 1
Length of output: 19368
libs/application/templates/accident-notification/src/utils/documentUtils.ts (1)
179-203:
Review logic in hasMissingDocuments function
In the hasMissingDocuments function, the conditions might not cover all scenarios accurately. Ensure that the logic correctly identifies all cases where documents are missing, especially when combining multiple conditions.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/applicantInformationSection.ts (1)
Line range hint 1-8: Verify integration of applicantInformationMultiField
Ensure that the applicantInformationMultiField() function imported from @island.is/application/ui-forms is compatible and integrates seamlessly within this section. Verify that all required props and configurations are correctly set.
libs/application/templates/accident-notification/src/utils/dateUtils.ts (1)
13-16: Improved type safety by specifying generic type
Specifying the generic type <string> in the getValueViaPath function enhances type safety and eliminates the need for type casting. This is a good use of TypeScript features.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/childInCustodySubSection.ts (1)
7-7: Import reorganization looks good
The utility function import has been properly organized into a specific utils file, improving code organization.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/studiesAccidentSubSection.ts (1)
8-8: LGTM! Import reorganization aligns with PR objectives.
The change to import from a more specific path (utils/accidentUtils) improves code organization.
Let's verify the consistency of this reorganization:
✅ Verification successful
Import reorganization is consistently applied across the codebase
The verification shows that all accident-related utility imports are consistently using the new path utils/accidentUtils, including:
isStudiesAccidentisFatalAccidentisWorkAccidentisHomeActivitiesAccidentisRescueWorkAccident
No files are using the old import path, confirming the reorganization is complete.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if other files are also using the new import path
rg "import.*from.*utils/accidentUtils"
# Check if there are any remaining imports from the old path
rg "import.*isStudiesAccident.*from.*utils['\"]"
Length of output: 1659
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/powerOfAttorneyUploadSubSection.ts (2)
9-9: LGTM! Import reorganization improves code structure.
Moving the import to documentUtils aligns with the utility reorganization objective.
Let's verify the consistency of document-related utility imports:
✅ Verification successful
Import reorganization is correctly implemented and consistent
The verification confirms that:
- The
isUploadNowfunction is properly implemented indocumentUtils.ts - The new import path is being used consistently across the codebase
- No references to the old import path remain
- The function's implementation is correctly handling document upload logic
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if other files are using the new documentUtils path
rg "import.*from.*utils/documentUtils"
# Check for any remaining old import paths
rg "import.*isUploadNow.*from.*utils/isUploadNow"
Length of output: 640
Script:
#!/bin/bash
# Let's verify the implementation and usage of isUploadNow function
ast-grep --pattern 'export function isUploadNow'
# Check for any other imports of isUploadNow from any path
rg "import.*\{.*isUploadNow.*\}.*from"
# Check the content of documentUtils file
fd documentUtils.ts --exec cat {}
Length of output: 9308
14-14: Verify the impact of the new condition.
The addition of the condition property is a functional change that goes beyond utility reorganization.
Let's analyze the usage of this condition:
✅ Verification successful
The condition is a standard form control mechanism with no unexpected impact
The isUploadNow function is a utility function that determines whether to show the power of attorney upload section based on the user's selection in the form. This is a common pattern used throughout the codebase for conditional form rendering. The implementation shows it's properly tested and only affects the visibility of its own section, without any side effects on other parts of the application.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other uses of isUploadNow in conditions
ast-grep --pattern 'condition: $_ => isUploadNow($_)'
Length of output: 55
Script:
#!/bin/bash
# Search for isUploadNow function definition and usage
rg "isUploadNow" -A 3
# Search for any condition property in the same file
rg "condition:" libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/powerOfAttorneyUploadSubSection.ts -A 3
Length of output: 4913
Script:
#!/bin/bash
# Let's check the implementation of isUploadNow to understand its functionality
cat libs/application/templates/accident-notification/src/utils/documentUtils.ts
# Let's also check if there are any other subsections using similar conditions
rg "buildSubSection" -A 10
Length of output: 92341
libs/application/templates/accident-notification/src/fields/FormOverview/ValueLine.tsx (2)
14-14: LGTM! Component definitions follow best practices.
The component definitions without React.FC improve code clarity and follow TypeScript best practices.
Also applies to: 30-30
8-12: LGTM! Type definition improvements enhance type safety.
Converting from interface to type and removing React.FC aligns with modern TypeScript practices.
Let's check for consistency in type definitions across components:
✅ Verification successful
Type definition changes are localized and consistent
The changes to ValueLineProps are well-contained within the file and follow consistent patterns. The file also defines a similar FileValueLineProps interface, showing consistent type usage. The conversion from interface to type and removal of React.FC is a safe modernization that doesn't impact other parts of the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other React.FC usages that might need similar updates
rg "React\.FC"
# Look for similar prop type patterns
ast-grep --pattern 'type $_ = {
$$$
}'
Length of output: 65793
Script:
#!/bin/bash
# Let's check for similar prop type patterns in the same directory
rg -A 5 "type.*Props.*=.*{" libs/application/templates/accident-notification/src/fields/FormOverview/
# Check for any other files importing ValueLineProps
rg "ValueLineProps" libs/application/templates/accident-notification/src/
Length of output: 823
libs/application/templates/accident-notification/src/utils/dateUtils.spec.ts (1)
32-56: Well-structured test suite with comprehensive coverage!
The test suite for isValid24HFormatTime is well-implemented with:
- Good use of parameterized tests
- Coverage of valid cases (0000, 2359, 1234)
- Thorough invalid cases including edge cases (2400, empty string) and malformed inputs
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/juridicialPersonCompanySubSection.ts (1)
8-9: Clean import reorganization aligning with PR objectives!
The changes improve code organization by:
- Moving utility function to a dedicated
reportingUtilsmodule - Using shared constants from the core types package
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/workMachineSubSection.ts (2)
11-13: Clean import reorganization!
The changes improve code organization by:
- Moving occupation-related utilities to a dedicated module
- Using shared constants from the core types package
Line range hint 19-22: Verify the impact of adding sport accidents to work machine section
The condition now includes sport accidents for employees. Let's verify this business logic change.
✅ Verification successful
Including sport accidents in work machine section is valid
Based on the test cases and implementation, this is a valid business logic change. The tests confirm that sport accidents where the person is an employee (on payroll) should be treated similarly to workplace accidents regarding work machine information. This is evidenced by:
- The
isSportAccidentAndEmployeefunction checks both the accident type (SPORTS) and employment status (onPayRoll) - Test cases explicitly verify this logic: "should return true for sport accidents where the person is also an employee of the sports club"
- The function is used consistently across location and work machine subsections
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for related test cases or documentation about work machine requirements for sport accidents
rg -A 5 "workMachine.*sport"
rg -A 5 "sport.*workMachine"
# Look for similar patterns in other accident types
ast-grep --pattern 'condition: $_formValue => isGeneralWorkplaceAccident($_formValue) || $_'
Length of output: 156
Script:
#!/bin/bash
# Search for test files related to sport accidents and work machines
fd -e test.ts -e spec.ts | xargs rg -l "isSportAccidentAndEmployee|workMachine"
# Search for the implementation of isSportAccidentAndEmployee
ast-grep --pattern 'export const isSportAccidentAndEmployee = ($_) => { $$$ }'
# Look for documentation about accident types
fd "README|SPEC" | xargs rg -l "sport.*accident|work.*machine"
# Search for any form validation or schema related to work machines in sport accidents
rg -A 5 "workMachine.*validation|workMachine.*schema"
Length of output: 444
Script:
#!/bin/bash
# Check the test file content for sport accident and work machine related tests
cat libs/application/templates/accident-notification/src/utils/occupationUtils.spec.ts
# Check README content for work machines domain
cat libs/api/domains/work-machines/README.md
cat libs/clients/work-machines/README.md
# Look for the actual implementation of isSportAccidentAndEmployee
rg -A 5 "isSportAccidentAndEmployee"
Length of output: 20336
libs/application/templates/accident-notification/src/utils/accidentUtils.ts (1)
54-60: LGTM: isFatalAccident implementation
The function is well-typed and follows the established pattern for checking form values.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/whoIsTheNotificationForSection/injuredPersonInformationSubSection.ts (1)
11-11: LGTM: Import path update
The import path change aligns with the PR objective of reorganizing utility files.
libs/application/templates/accident-notification/src/fields/FormOverviewInReview/ConfirmationModal.tsx (2)
Line range hint 9-20: LGTM: Props type definition
Clean and well-structured props interface with appropriate optional properties.
Line range hint 22-33: LGTM: Component signature update
The simplified component signature improves readability while maintaining type safety.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/accidentDetailSubSection.ts (1)
11-13: LGTM! Good utility organization
The reorganization of utility functions into specific modules (dateUtils, miscUtils, accidentUtils) improves code maintainability and follows good separation of concerns.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/companyInfoSubSection.ts (1)
13-16: LGTM: Well-organized utility imports
The reorganization of utility functions into specific categories (occupation, reporting, accident, misc) improves code organization and maintainability.
Let's verify the utility functions are properly exported from their respective files:
✅ Verification successful
Verified: Utility functions are properly organized and exported
All utility functions are correctly exported from their respective categorized files:
isHomeActivitiesAccidentin accidentUtils.tsisReportingOnBehalfOfEmployeein reportingUtils.tsisInjuredAndRepresentativeOfCompanyOrInstitutein miscUtils.ts
Each function has proper implementation and corresponding test files (.spec.ts) exist for all utility modules.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify utility functions are properly exported
# Test: Check if the utility files exist and export the required functions
rg -l "export.*(?:isHomeActivitiesAccident|isReportingOnBehalfOfEmployee|isInjuredAndRepresentativeOfCompanyOrInstitute)" "utils/"
Length of output: 177
Script:
#!/bin/bash
# Let's search from the repository root with correct paths
rg -l "export.*(?:isHomeActivitiesAccident|isReportingOnBehalfOfEmployee|isInjuredAndRepresentativeOfCompanyOrInstitute)" libs/application/templates/accident-notification/src/utils/
Length of output: 408
Script:
#!/bin/bash
# Let's also check the actual implementation of these functions
rg "export.*(?:isHomeActivitiesAccident|isReportingOnBehalfOfEmployee|isInjuredAndRepresentativeOfCompanyOrInstitute)" -A 5 libs/application/templates/accident-notification/src/utils/
Length of output: 2249
Script:
#!/bin/bash
# Verify if the utility files exist
fd . libs/application/templates/accident-notification/src/utils/ -t f
Length of output: 1232
libs/application/templates/accident-notification/src/fields/FormOverviewInReview/index.tsx (1)
20-25: LGTM: Clean component signature
The destructured props and explicit typing improve code readability and maintainability.
libs/application/templates/accident-notification/src/utils/accidentUtils.spec.ts (2)
12-32: LGTM: Comprehensive test coverage for isHomeActivitiesAccident
Tests cover the main scenarios including valid input, invalid input, and empty object case.
139-157: LGTM: Clear and concise tests for isFatalAccident
Tests cover all necessary cases for the fatal accident check.
libs/application/templates/accident-notification/src/lib/dataSchema.ts (1)
102-102: LGTM: Consistent use of YesOrNo enum
The standardization of boolean fields using the YesOrNo enum improves type safety and maintains consistency across the schema.
Also applies to: 196-197, 216-217, 222-222, 243-243
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/attachmentsSubSection.ts (2)
18-18: LGTM: Well-organized utility imports
The reorganization of utility functions into specific files (miscUtils, constants, reportingUtils, accidentUtils) improves code maintainability and follows the single responsibility principle.
Also applies to: 20-23
Line range hint 93-95: LGTM: Clear and maintainable condition checks
The condition functions effectively utilize the utility functions and maintain clear logic for showing/hiding form sections.
Also applies to: 124-127, 147-150
libs/application/templates/accident-notification/src/utils/documentUtils.spec.ts (3)
1-21: LGTM! Well-organized imports and test data setup.
The imports are logically grouped, and the test data setup is clear and purposeful.
32-55: LGTM! Well-implemented test suite with proper mock handling.
The test cases effectively verify the error message generation with:
- Proper mock setup and cleanup
- Coverage of both missing and no missing document scenarios
243-316: LGTM! Well-structured test cases with good coverage.
The test suites for returnMissingDocumentsList and isUploadNow are well-implemented with:
- Clear test scenarios
- Good coverage of edge cases
- Proper mock handling
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/locationSubSection.ts (1)
23-37: LGTM! Well-organized utility imports.
The reorganization of utility imports into specific categories (occupationUtils, accidentUtils, miscUtils) improves code organization and maintainability.
libs/application/templates/accident-notification/src/forms/AccidentNotificationForm/aboutTheAccidentSection/fishingCompanyInfoSubSection.ts (1)
Line range hint 1-124: Verify cross-app compatibility of the form builders
Since this code resides in the libs directory, let's verify its usage across different NextJS apps to ensure proper reusability.
✅ Verification successful
Let me gather more information about the form builders' usage to make a conclusive verification.
Let me try one final verification focusing on the application core package where these builders are defined.
Based on the comprehensive search results, I can now provide a final response:
Form builders are properly shared and widely used across applications
The form builders (buildSubSection, buildTextField, buildMultiField) from @island.is/application/core are:
- Defined in the core package (
libs/application/core/src/lib/fieldBuilders.tsandlibs/application/core/src/lib/formBuilders.ts) - Used extensively across multiple application templates in the
libs/application/templates/directory - Consistently implemented across different types of forms (health insurance, driving license, passport, etc.)
The usage in the accident notification form follows the same patterns as other applications, ensuring proper reusability and consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of the form builders across different apps
echo "Searching for form builder usage across apps..."
rg -l "buildSubSection|buildTextField|buildMultiField" "apps/"
# Check for potential circular dependencies
echo "Checking for potential circular dependencies..."
rg -l "fishingCompanyInfoSubSection" "libs/application/templates/accident-notification/src/"
Length of output: 620
Script:
#!/bin/bash
# Search for form builder imports and usage in the entire codebase
echo "Searching for form builder imports..."
rg -l "@island.is/application/core.*build(SubSection|TextField|MultiField)" --type ts
# Check the actual implementation of these builders
echo "Checking builder implementations..."
ast-grep --pattern 'export const build(SubSection|TextField|MultiField) = $_'
Length of output: 333
Script:
#!/bin/bash
# Check the application core package for builder definitions
echo "Searching in application core..."
fd -t f . libs/application/core -x rg -l "export.*build(SubSection|TextField|MultiField)"
# Check if these builders are used in other templates
echo "Checking usage in other templates..."
fd -t f . libs/application/templates -x rg -l "build(SubSection|TextField|MultiField)"
Length of output: 40138
libs/application/templates/accident-notification/src/fields/FormOverview/index.tsx
Show resolved
Hide resolved
libs/application/templates/accident-notification/src/fields/ProxyDocument/index.tsx
Show resolved
Hide resolved
libs/application/templates/accident-notification/src/utils/accidentUtils.ts
Show resolved
Hide resolved
...ation/templates/accident-notification/src/fields/ApplicationStatus/applicationStatusUtils.ts
Show resolved
Hide resolved
libs/application/templates/accident-notification/src/utils/documentUtils.spec.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (9)
libs/application/templates/accident-notification/src/utils/miscUtils.ts (5)
30-44: Enhance type safety and naming.The function handles confirmation validation well, but type safety could be improved.
Consider these improvements:
-export const hasReceivedConfirmation = (answers: FormValue) => { +export const hasRequiredConfirmations = (answers: FormValue): boolean => { const accidentConfirmations = getValueViaPath( answers, 'accidentStatus.receivedConfirmations', - ) as AccidentNotificationConfirmation + ) + + if (!accidentConfirmations || typeof accidentConfirmations !== 'object') { + return false + } + + const confirmations = accidentConfirmations as AccidentNotificationConfirmation
46-62: Simplify the return condition for better readability.The function logic is correct but could be more concise.
Consider this optimization:
- return ( - answer === GeneralWorkplaceAccidentLocationEnum.ATTHEWORKPLACE || - answer === StudiesAccidentLocationEnum.ATTHESCHOOL || - answer === ProfessionalAthleteAccidentLocationEnum.SPORTCLUBSFACILITES - ) + const mainLocations = [ + GeneralWorkplaceAccidentLocationEnum.ATTHEWORKPLACE, + StudiesAccidentLocationEnum.ATTHESCHOOL, + ProfessionalAthleteAccidentLocationEnum.SPORTCLUBSFACILITES, + ] + return mainLocations.includes(answer)
64-122: LGTM! Well-structured utility functions with clear purposes.The boolean check functions are well-implemented. Consider adding JSDoc comments to document the business rules they implement, especially for complex conditions like
shouldRequestReview.
124-134: Document the purpose of delegation pattern.While the delegation implementation is clean, it would be helpful to understand why these functions are delegated rather than directly imported from their original locations.
Add JSDoc comments explaining the delegation strategy:
+/** + * Delegates to the original implementation to maintain a single entry point + * for all utility functions while allowing for future customization if needed. + */ export const isReportingOnBehalfOfEmployee = (answers: FormValue) => { return isReportingOnBehalfOfEmployeeOrginal(answers) }
1-134: Excellent adherence to coding guidelines.The implementation successfully meets the requirements for libs directory:
- ✅ Functions are reusable across different NextJS apps
- ✅ Strong TypeScript usage with proper type definitions
- ✅ Effective tree-shaking support through named exports
libs/application/templates/accident-notification/src/utils/documentUtils.ts (4)
87-109: Simplify nested conditions and fix typoThe
hasReceivedAllDocumentsfunction could be simplified for better readability.Consider this refactoring:
export const hasReceivedAllDocuments = (answers: FormValue) => { - // Reporting for self or as juridicial person only injury certificate relevent + // Reporting for self or as juridical person only injury certificate relevant if ( isReportingOnBehalfSelf(answers) || isReportingOnBehalfOfEmployee(answers) ) { return hasReceivedInjuryCertificate(answers) } else { - // If fatal and not report for self or as juridicial all documents are relevant - if (isFatalAccident(answers)) { - return ( - hasReceivedPoliceReport(answers) && - hasReceivedProxyDocument(answers) && - hasReceivedInjuryCertificate(answers) - ) - } else { - return ( - hasReceivedProxyDocument(answers) && - hasReceivedInjuryCertificate(answers) - ) - } + const baseRequirements = + hasReceivedProxyDocument(answers) && + hasReceivedInjuryCertificate(answers) + + return isFatalAccident(answers) + ? baseRequirements && hasReceivedPoliceReport(answers) + : baseRequirements } }
53-57: Remove unnecessary default valueThe default value
[{ key: '', name: '' }]ingetValueViaPathforinjuryCertificateFileseems unnecessary since thehasAttachmentfunction already handles undefined values.const injuryCertificateFile = getValueViaPath<Array<FileType>>( answers, - 'attachments.injuryCertificateFile.file', - [{ key: '', name: '' }], + 'attachments.injuryCertificateFile.file' )
111-153: Enhance type safety for error messagesConsider creating a dedicated type for the document names to ensure type safety when using
formatMessage.type DocumentMessageKeys = { injuryCertificate: string powerOfAttorneyDocument: string deathCertificate: string } // This ensures type safety when accessing message keys const documentMessages: DocumentMessageKeys = { injuryCertificate: attachments.documentNames.injuryCertificate, powerOfAttorneyDocument: attachments.documentNames.powerOfAttorneyDocument, deathCertificate: attachments.documentNames.deathCertificate }
179-203: Reduce duplication in file path accessConsider extracting the common file path access pattern into a helper function.
+const getAttachmentFile = (answers: FormValue, fileType: string) => + getValueViaPath<Array<FileType>>( + answers, + `attachments.${fileType}File.file`, + ) + export const hasMissingDocuments = (answers: FormValue) => { - const injuryCertificateFile = getValueViaPath<Array<FileType>>( - answers, - 'attachments.injuryCertificateFile.file', - ) - - const deathCertificateFile = getValueViaPath<Array<FileType>>( - answers, - 'attachments.deathCertificateFile.file', - ) - - const powerOfAttorneyFile = getValueViaPath<Array<FileType>>( - answers, - 'attachments.powerOfAttorneyFile.file', - ) + const injuryCertificateFile = getAttachmentFile(answers, 'injuryCertificate') + const deathCertificateFile = getAttachmentFile(answers, 'deathCertificate') + const powerOfAttorneyFile = getAttachmentFile(answers, 'powerOfAttorney')
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
libs/application/templates/accident-notification/src/utils/documentUtils.ts(1 hunks)libs/application/templates/accident-notification/src/utils/miscUtils.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
libs/application/templates/accident-notification/src/utils/miscUtils.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/application/templates/accident-notification/src/utils/documentUtils.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/application/templates/accident-notification/src/utils/miscUtils.ts (1)
1-22: LGTM! Well-organized imports with clear type definitions.
The imports are logically structured and follow good practices for TypeScript usage.
libs/application/templates/accident-notification/src/utils/documentUtils.ts (2)
1-22: LGTM! Clean and well-organized imports
The imports are logically grouped and properly typed.
282-295: LGTM! Clean implementation of upload status check
The function is well-typed and focused on a single responsibility.
libs/application/templates/accident-notification/src/utils/documentUtils.ts
Show resolved
Hide resolved
…d.is into chore/a-n-organize-utils
libs/application/templates/accident-notification/src/lib/messages/externalData.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
libs/application/templates/accident-notification/src/utils/getOptions.spec.ts (1)
Line range hint
6-48: Consider adding test cases for error scenarios.While the current test coverage is good for valid inputs, consider adding test cases for potential error scenarios:
- Invalid
whoIsTheNotificationForvalues- Malformed
FormValueobjectsundefinedornullinputs
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
libs/application/templates/accident-notification/src/utils/documentUtils.spec.ts(1 hunks)libs/application/templates/accident-notification/src/utils/getOptions.spec.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- libs/application/templates/accident-notification/src/utils/documentUtils.spec.ts
🧰 Additional context used
📓 Path-based instructions (1)
libs/application/templates/accident-notification/src/utils/getOptions.spec.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 (1)
libs/application/templates/accident-notification/src/utils/getOptions.spec.ts (1)
3-3: Verify tree-shaking implications of consolidated utils.
The import change aligns with the PR objective of organizing utils. However, since this file is under libs/**/*, we should verify that consolidating functions into getOptions.ts doesn't negatively impact tree-shaking.
✅ Verification successful
Let me check the actual exports from getOptions.ts to make a proper assessment about tree-shaking.
Tree-shaking is properly maintained in the consolidated utils file
The consolidation of functions in getOptions.ts follows good practices for tree-shaking:
- Each function is exported individually using named exports
- The imports are only used in 3 specific files that need these functions
- The functions are not re-exported through barrel files
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if getOptions.ts exports other functions that might affect tree-shaking
# Check exports from getOptions.ts
ast-grep --pattern 'export $$$' libs/application/templates/accident-notification/src/utils/getOptions.ts
# Check imports of getOptions.ts across the codebase
rg -l "from ['\"].*getOptions['\"]" --type ts
Length of output: 522
Script:
#!/bin/bash
# Get the content of getOptions.ts to analyze exports and their usage
cat libs/application/templates/accident-notification/src/utils/getOptions.ts
Length of output: 1982
What
Organize utils in accident-notification
Why
Folder was getting very bloated and it was hard to get an overview of what was going on there
Checklist:
Summary by CodeRabbit
New Features
StatusStepcomponent with improved action handling and visibility properties.Bug Fixes
Refactor
ChoiceEnumwithYesOrNofor improved type safety in data schemas.Tests