[Missions] Modifier les styles des champs en erreurs en rouge allégé #3019
Conversation
|
Warning Rate Limit Exceeded@louptheron has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 16 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. WalkthroughThe recent changes aim to enhance the mission form experience by introducing Changes
Assessment against linked issues
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (24)
- frontend/cypress/e2e/side_window/mission_form/air_control.spec.ts (2 hunks)
- frontend/cypress/e2e/side_window/mission_form/air_surveillance.spec.ts (2 hunks)
- frontend/cypress/e2e/side_window/mission_form/land_control.spec.ts (3 hunks)
- frontend/cypress/e2e/side_window/mission_form/observation.spec.ts (1 hunks)
- frontend/cypress/e2e/side_window/mission_form/sea_control.spec.ts (3 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/AirControlForm.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/LandControlForm.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/ObservationForm.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/SeaControlForm.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/schemas.ts (4 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/ControlQualityField.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/FormikAuthor.tsx (2 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/FormikCoordinatesPicker.tsx (3 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/FormikPortSelect.tsx (3 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/GearsField.tsx (4 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/LicencesAndLogbookField.tsx (4 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/SpeciesField.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionForm/shared/VesselField.tsx (2 hunks)
- frontend/src/features/Mission/components/MissionForm/MainForm/FormikDoubleDatePicker.tsx (3 hunks)
- frontend/src/features/Mission/components/MissionForm/MainForm/FormikMultiControlUnitPicker/ControlUnitSelect.tsx (2 hunks)
- frontend/src/features/Mission/components/MissionForm/MainForm/index.tsx (2 hunks)
- frontend/src/features/Mission/components/MissionForm/MainForm/schemas.ts (1 hunks)
- frontend/src/features/Mission/components/MissionForm/constants.tsx (1 hunks)
- frontend/src/features/SideWindow/Alert/SilencedAlerts/tests/schema.test.ts (2 hunks)
Additional comments: 50
frontend/src/features/Mission/components/MissionForm/ActionForm/shared/FormikAuthor.tsx (2)
- 1-1: The import of
HIDDEN_ERRORis correctly implemented, aligning with the PR's objective to standardize error handling.- 16-16: The addition of the
isRequiredprop to theFormikTextInputcomponent for "Saisi par" is a good enhancement, ensuring that the field is marked as required in the UI. This aligns with the PR's goal to improve form validation and user experience.frontend/src/features/Mission/components/MissionForm/MainForm/schemas.ts (2)
- 3-3: The import of
HIDDEN_ERRORis correctly implemented, supporting the standardized error handling approach in the schemas.- 8-24: Replacing specific error messages with
HIDDEN_ERRORin theControlUnitSchemaandMainFormLiveSchemais a positive change. It standardizes error handling across the form, contributing to a cleaner and more consistent user experience.frontend/src/features/SideWindow/Alert/SilencedAlerts/__tests__/schema.test.ts (2)
- 1-1: The import of
HIDDEN_ERRORis correctly implemented, ensuring that the test cases align with the new error handling strategy.- 40-40: Replacing a specific error message check with a check for
HIDDEN_ERRORin the test case is a good practice. It ensures consistency with the new error handling strategy.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/ControlQualityField.tsx (1)
- 11-13: Adding
isErrorMessageHiddenandisRequiredprops to theFormikMultiRadiocomponent enhances form usability by clearly indicating required fields and controlling the display of error messages. This aligns with the PR's objectives to improve form validation and user experience.frontend/src/features/Mission/components/MissionForm/MainForm/FormikDoubleDatePicker.tsx (3)
- 1-1: The import of
HIDDEN_ERRORis correctly implemented, supporting the changes made in this file related to error handling.- 21-21: Updating the
FormikDatePickercomponent props to includeisRequiredfor both start and end dates ensures that these fields are marked as required in the UI. This is a good enhancement, aligning with the PR's goal to improve form validation and user experience.Also applies to: 32-32
- 39-39: Modifying the error display logic to exclude
HIDDEN_ERRORprevents unnecessary error messages from cluttering the UI, contributing to a cleaner user experience. This aligns with the PR's objectives.frontend/src/features/Mission/components/MissionForm/ActionForm/ObservationForm.tsx (1)
- 41-41: Adding
isErrorMessageHiddenandisRequiredprops to theFormikTextInputcomponent for "Saisi par" enhances form usability by clearly indicating required fields and controlling the display of error messages. This aligns with the PR's objectives to improve form validation and user experience.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/LicencesAndLogbookField.tsx (1)
- 11-13: Adding the
isRequiredprop and setting theisErrorMessageHiddenprop totrueforFormikMultiRadiocomponents enhances form usability by clearly indicating required fields and controlling the display of error messages. This aligns with the PR's objectives to improve form validation and user experience.Also applies to: 23-25, 35-37, 47-49
frontend/src/features/Mission/components/MissionForm/constants.tsx (1)
- 88-88: Adding the
HIDDEN_ERRORconstant is a key part of the strategy to standardize error handling across the application. This facilitates the implementation of a cleaner UI by allowing error messages to be hidden when not needed.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/FormikPortSelect.tsx (3)
- 2-2: The import of
HIDDEN_ERRORis correctly implemented and aligns with the project's standards for managing constants. This approach facilitates consistent error handling across the application.- 98-100: The conditional rendering logic using
HIDDEN_ERRORto hide the error message whenerrors.portLocodeequalsHIDDEN_ERRORis correctly implemented. This enhances the user experience by refining error display according to the PR's objectives.- 83-92: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-100]
The overall logic of the
FormikPortSelectcomponent, including API calls, memoization, and form handling, is sound. The introduction ofHIDDEN_ERRORenhances error handling without affecting the core functionality.frontend/src/features/Mission/components/MissionForm/ActionForm/AirControlForm.tsx (1)
- 60-62: The addition of
isErrorMessageHiddenandisRequiredprops to theFormikDatePickercomponent enhances form component behavior by allowing for more controlled display of error messages and marking fields as required based on specific conditions. This aligns with the PR's objectives to improve the user experience and form validation.frontend/cypress/e2e/side_window/mission_form/observation.spec.ts (1)
- 99-110: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-100]
Based on the summary, it appears that the test has been adjusted to reflect the removal of a validation message after filling out the "Saisi par" field. It's important to verify that these test adjustments accurately reflect the updated form behavior, ensuring that tests remain relevant and effective.
frontend/src/features/Mission/components/MissionForm/ActionForm/LandControlForm.tsx (1)
- 73-75: The addition of
isErrorMessageHiddenandisRequiredprops to theFormikDatePickercomponent inLandControlForm.tsxis consistent with the PR's objectives, enhancing form component behavior by allowing for more nuanced control over error message display and field requirements.frontend/src/features/Mission/components/MissionForm/ActionForm/SeaControlForm.tsx (1)
- 73-75: The addition of
isErrorMessageHiddenandisRequiredprops to theFormikDatePickercomponent inSeaControlForm.tsximproves the form's usability by providing clearer feedback to the user regarding required fields and error messages. This consistency in enhancing form component behavior across different forms is commendable.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/VesselField.tsx (2)
- 1-1: The import of
HIDDEN_ERRORis correctly implemented and aligns with the project's standards for managing constants. This approach facilitates consistent error handling across the application.- 136-136: The conditional rendering logic using
HIDDEN_ERRORto hide the error message for thevesselIdfield when it equalsHIDDEN_ERRORis correctly implemented. This enhances the user experience by refining error display according to the PR's objectives.frontend/cypress/e2e/side_window/mission_form/air_control.spec.ts (1)
- 123-139: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-100]
Based on the summary, it appears that the test has been adjusted to reflect the updated form behavior, specifically the adjustment of live validation messages for missing fields. It's important to verify that these test adjustments accurately reflect the updated form behavior, ensuring that tests remain relevant and effective.
frontend/src/features/Mission/components/MissionForm/ActionForm/schemas.ts (2)
- 3-3: The import of
HIDDEN_ERRORis correctly implemented and aligns with the project's standards for managing constants. This approach facilitates consistent error handling across the application.- 45-156: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [13-165]
The replacement of specific error messages with the
HIDDEN_ERRORconstant in various validation rules throughout the file is consistent with the PR's objectives to standardize error handling. This approach simplifies error handling by using a constant to represent hidden errors, improving maintainability and consistency across form validations.frontend/src/features/Mission/components/MissionForm/MainForm/index.tsx (2)
- 92-92: The addition of the
isRequiredprop to theFormikMultiCheckboxcomponent for "Types de mission" is a good practice to ensure that users cannot submit the form without specifying the mission types. This change aligns with the objective of enhancing form validation and user experience.- 119-120: Adding the
isRequiredprop to theFormikTextInputcomponents for "Ouvert par" and "Clôturé par" fields ensures that these fields must be filled before the form can be submitted. This is a crucial step towards improving form validation and preventing incomplete submissions.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/FormikCoordinatesPicker.tsx (3)
- 1-1: The import of the
HIDDEN_ERRORconstant is a good addition, as it allows for a standardized approach to handling hidden errors across the application. This aligns with the objective of refining error handling and improving the consistency of validation messaging.- 149-156: Adding the
error,isErrorMessageHidden, andisRequiredprops to theFormikCoordinatesPickercomponent enhances its functionality and user interaction. These changes allow for conditional error message display and marking the field as required, which contributes to a more intuitive and user-friendly form experience.- 166-166: Conditionally rendering the
FieldErrorcomponent based on theerrorvalue and excluding it when the error is equal toHIDDEN_ERRORis a smart way to manage error visibility. This ensures that errors are only displayed when necessary, keeping the UI clean and user-friendly.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/GearsField.tsx (4)
- 3-3: The import of the
HIDDEN_ERRORconstant in theGearsFieldcomponent is a positive change, as it supports a more unified and cleaner approach to error handling within the form. This constant allows for the selective display of error messages, improving the user interface.- 110-112: Adding the
isErrorMessageHiddenandisRequiredprops to theFormikMultiRadiocomponent within theGearsFieldcomponent is a good practice. It ensures that the error messages are managed appropriately and that the field is marked as required when necessary, enhancing form validation.- 160-162: The addition of the
error,isErrorMessageHidden, andisRequiredprops to theSelectcomponent for adding gears is a thoughtful update. It ensures that the component behaves correctly in terms of error handling and requirement indication, contributing to a better user experience.- 171-173: Conditionally rendering the
StyledFieldErrorbased on themeta.errorand excluding it when the error equalsHIDDEN_ERRORis an effective way to manage error visibility. This approach keeps the UI clean and focuses the user's attention only on relevant errors.frontend/src/features/Mission/components/MissionForm/ActionForm/shared/SpeciesField.tsx (3)
- 133-135: Adding the
isErrorMessageHidden,isRequired, and updating the label for theFormikMultiRadiocomponent related to species weight verification is a significant improvement. It ensures that the field is marked as required and that error messages are managed appropriately, enhancing form validation and clarity.- 141-143: The addition of the
isErrorMessageHidden,isRequired, and updated label for theFormikMultiRadiocomponent related to species size verification aligns with the goal of improving form validation and user experience. These changes ensure that the field is correctly marked as required and that error messages are handled properly.- 149-151: Adding the
isErrorMessageHidden,isRequired, and updated label for theFormikMultiRadiocomponent related to separate stowage of preserved species is a thoughtful update. It enhances the form's clarity and validation by ensuring that the field is marked as required and that error messages are managed effectively.frontend/src/features/Mission/components/MissionForm/MainForm/FormikMultiControlUnitPicker/ControlUnitSelect.tsx (2)
- 186-186: The conditional addition of the
isRequiredprop to theAdministrationfield based on theindexvalue is a smart way to ensure that the first control unit's administration is always marked as required. This enhances form validation and ensures that essential information is collected.- 200-200: Similarly, adding the
isRequiredprop conditionally to theUnitéfield based on theindexvalue ensures that the first control unit's name is always required. This approach improves form validation and data integrity by ensuring that key details are provided.frontend/cypress/e2e/side_window/mission_form/sea_control.spec.ts (11)
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
The import statements and context setup at the beginning of the file are standard for Cypress tests and provide necessary utilities and constants for the tests. No changes are needed here.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [7-7]
The
beforeEachhook correctly sets up the environment for each test by opening a new mission form. This ensures that each test starts with a clean state.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [9-9]
The test case "Should fill the form with an unknown vessel and send the expected data to the API" is well-structured and follows a clear sequence of actions to simulate user interaction with the form. It also correctly intercepts the API request to assert the expected request payload.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [51-51]
The test case "Should fill the form and send the expected data to the API" demonstrates comprehensive form filling and validation of the request payload. It includes a variety of form fields and user interactions, providing a thorough test of the form's functionality.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [153-153]
The test case "Should fill the form for a vessel with logbook and prefill the gears, species, fao areas and segments fields" effectively tests the prefilling of form fields based on a selected vessel. It ensures that the form behaves as expected when data is preloaded.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [213-213]
The test case "Should only close mission once the form closure validation has passed" checks the form's validation logic before allowing the mission to be closed. This is crucial for ensuring data integrity and completeness before submission.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [273-273]
The test case "Should add, edit, remove and validate gears infractions as expected" covers the functionality related to managing infractions within the form. It tests adding, editing, and removing infractions, which is important for dynamic form interactions.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [333-333]
The test case "Should fill the mission zone from the last sea control added" verifies that the mission zone is correctly updated based on the last sea control action. This is important for ensuring that the mission's geographic data is accurate and up-to-date.
- 405-405: The test case "Should remove the other control fields When the previous PAM control unit is modified" checks the dynamic behavior of the form when control units are changed. It ensures that irrelevant fields are hidden or removed, maintaining form relevance and clarity.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [453-453]
The test case "Should add a PAM control unit and send the other control fields" tests the addition of a specific type of control unit and the display of related fields. This ensures that the form adapts correctly to different control scenarios.
- 378-393: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [495-495]
The test case "Should update (PUT) a control right after creating a new control (and not create a new one with POST)" ensures that updates to a newly created control are handled correctly without creating duplicate entries. This is important for maintaining data integrity and avoiding unnecessary API calls.
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (3)
- frontend/cypress/e2e/side_window/mission_form/main_form.spec.ts (3 hunks)
- frontend/cypress/e2e/side_window/mission_form/utils.ts (2 hunks)
- frontend/src/features/Mission/useCases/autoSaveMissionAction.ts (2 hunks)
Additional comments: 3
frontend/cypress/e2e/side_window/mission_form/utils.ts (1)
- 2-3: The addition of
customDayjsandgetUtcDateInMultipleFormatsto dynamically calculate the 'Fin de mission' end date enhances the test's flexibility. Ensure that the date format and timezone used align with the application's expectations and handling.Also applies to: 97-98
Verification successful
The
getUtcDateInMultipleFormatsfunction infrontend/cypress/e2e/utils/getUtcDateInMultipleFormats.tscorrectly handles dates in UTC format, providing multiple formats for use in tests, including ISO strings and tuples. This ensures that the date format and timezone handling align with common application expectations for date manipulation and formatting, especially in a testing context where consistency and precision are crucial.Given the function's implementation, it appears to be well-designed for its intended purpose of providing various date formats, particularly in UTC, which is a standard practice for handling dates in web applications to avoid timezone-related issues.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that the date format and timezone handling in getUtcDateInMultipleFormats align with the application's expectations. cat frontend/cypress/utils/getUtcDateInMultipleFormats.tsLength of output: 145
Script:
#!/bin/bash # Search for the file getUtcDateInMultipleFormats.ts across the repository to confirm its existence and correct path. fd getUtcDateInMultipleFormats.tsLength of output: 93
Script:
#!/bin/bash # Display the content of getUtcDateInMultipleFormats.ts to review its implementation. cat frontend/cypress/e2e/utils/getUtcDateInMultipleFormats.tsLength of output: 968
frontend/cypress/e2e/side_window/mission_form/main_form.spec.ts (2)
- 7-7: The addition of
getUtcDateInMultipleFormatsto dynamically calculate the 'Fin de mission' end date enhances the test's flexibility. Ensure that the date format and timezone used align with the application's expectations and handling.Also applies to: 49-50
Verification successful
The
getUtcDateInMultipleFormatsfunction, as revealed by the script output, is designed to handle dates in UTC format, providing multiple representations of a given date. This includes an encoded string version of the UTC date, a short string version without seconds, milliseconds, and timezone offset, the full UTC date string, and tuple representations both with and without time components. The use ofcustomDayjs(date).utc()ensures that the date is processed in UTC, aligning with the common practice for handling dates in web applications to avoid timezone-related issues.Given this information, it can be concluded that the function is well-suited for generating dates in formats that could align with various application requirements, especially in the context of testing where flexibility and precision in date handling are crucial. The function's design to explicitly work with UTC dates and provide multiple formats, including ISO strings and tuples, suggests careful consideration of common date format and timezone handling requirements.
Based on the provided implementation details, the addition of
getUtcDateInMultipleFormatsto dynamically calculate the 'Fin de mission' end date in the Cypress e2e tests for the main form of the side window mission form is verified to enhance the test's flexibility and precision. The function's approach to date and timezone handling appears to align well with typical application expectations, especially in scenarios requiring consistent and accurate date representations across different timezones.* 118-119: This comment is a duplicate of the previous one regarding the addition of `getUtcDateInMultipleFormats` for dynamically calculating the 'Fin de mission' end date. The same considerations apply.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that the date format and timezone handling in getUtcDateInMultipleFormats align with the application's expectations. cat frontend/cypress/utils/getUtcDateInMultipleFormats.tsLength of output: 145
Script:
#!/bin/bash # Attempt to locate the getUtcDateInMultipleFormats.ts file across the entire repository fd getUtcDateInMultipleFormats.tsLength of output: 93
Script:
#!/bin/bash # Display the content of getUtcDateInMultipleFormats.ts to review its implementation cat frontend/cypress/e2e/utils/getUtcDateInMultipleFormats.tsLength of output: 968
louptheron
changed the title
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- frontend/cypress/e2e/side_window/mission_form/main_form.spec.ts (6 hunks)
Files skipped from review as they are similar to previous changes (1)
- frontend/cypress/e2e/side_window/mission_form/main_form.spec.ts
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (3)
- frontend/src/features/Mission/components/MissionForm/index.tsx (1 hunks)
- frontend/src/features/Mission/components/MissionForm/shared/DraftCancellationConfirmationDialog.tsx (1 hunks)
- frontend/src/features/SideWindow/useCases/openSideWindowPath.ts (2 hunks)
Additional comments: 2
frontend/src/features/SideWindow/useCases/openSideWindowPath.ts (1)
- 17-28: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [11-27]
The changes to the
openSideWindowPathfunction, including the updated return type toPromise<boolean>and the use ofawaitwith dispatch calls, are appropriate and improve the function's predictability and readability. However, consider adding comments explaining the conditions under whichfalseandtrueare returned for future maintainability.frontend/src/features/Mission/components/MissionForm/shared/DraftCancellationConfirmationDialog.tsx (1)
- 23-47: The revisions to the dialog title and content, as well as the button accent adjustments, enhance clarity, consistency, and visual hierarchy. The introduction of the
Detailsstyled component is a good practice for emphasizing text. Consider adding comments explaining the purpose of theDetailsstyled component for future maintainability.
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- frontend/src/features/SideWindow/useCases/openSideWindowPath.ts (2 hunks)
Files skipped from review as they are similar to previous changes (1)
- frontend/src/features/SideWindow/useCases/openSideWindowPath.ts
|
Linked issues
Summary by CodeRabbit