-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Mission] Correction de la duplication de missions #3052
Conversation
WalkthroughThe recent changes focus on streamlining the handling of mission actions by removing duplication functionality and updating data processing logic. This refactoring simplifies the codebase by eliminating unnecessary features and improving the efficiency of managing mission actions. Changes
Assessment against linked issues
Possibly related issues
Poem
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (7)
- frontend/cypress/e2e/side_window/mission_form/action_list.spec.ts (1 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionList/FishActionCard.tsx (2 hunks)
- frontend/src/features/Mission/components/MissionForm/ActionList/index.tsx (3 hunks)
- frontend/src/features/Mission/components/MissionForm/tests/utils.test.ts (3 hunks)
- frontend/src/features/Mission/components/MissionForm/index.tsx (3 hunks)
- frontend/src/features/Mission/components/MissionForm/utils.tsx (2 hunks)
- frontend/src/features/Mission/useCases/saveMissionAndMissionActionsByDiff.ts (3 hunks)
Additional comments (9)
frontend/src/features/Mission/useCases/saveMissionAndMissionActionsByDiff.ts (1)
- 25-31: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [28-38]
The refactoring to use
getMissionActionsToCreateUpdateOrDelete
introduces a more descriptive and accurate handling of mission actions. This change improves the clarity of the operation being performed - creating, updating, or deleting mission actions based on the difference between the current and previous state. Ensure that the rest of the codebase that interacts with mission actions has been updated to accommodate this change in functionality.frontend/src/features/Mission/components/MissionForm/ActionList/FishActionCard.tsx (1)
- 20-20: The removal of the duplication feature from the
FishActionCard
component aligns with the PR's objective to address mission duplication issues. This change simplifies the component and reduces potential sources of error. Ensure that any UI elements or user interactions related to duplication have been appropriately adjusted or removed.frontend/src/features/Mission/components/MissionForm/utils.tsx (1)
- 21-41: The renaming of
getMissionActionsDataFromMissionActionsFormValues
togetMissionActionsToCreateUpdateOrDelete
and the update to its functionality represent a significant improvement in clarity and purpose. This change makes it easier to understand the function's role in handling mission actions, especially in the context of creating, updating, or deleting them. Ensure that all references to this function throughout the codebase have been updated to reflect the new name and functionality.frontend/src/features/Mission/components/MissionForm/ActionList/index.tsx (1)
- 23-28: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
The removal of the
onDuplicate
function from theActionList
component's props and handling is a clear step towards simplifying the component and eliminating potential sources of mission duplication. This change should help in addressing the duplication issues outlined in the PR objectives. Ensure that any UI elements or user interactions related to duplication have been appropriately adjusted or removed.frontend/cypress/e2e/side_window/mission_form/action_list.spec.ts (1)
- 34-39: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
The update to the test case to focus on sending expected data to the API when deleting a mission action aligns with the removal of the duplication feature from the application. This change ensures that the test suite remains relevant and accurately reflects the application's current functionality. Ensure that all test cases have been updated to reflect the removal of the duplication feature and that they adequately cover the new functionality.
frontend/src/features/Mission/components/MissionForm/__tests__/utils.test.ts (1)
- 171-274: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [9-184]
The updates to the test cases for
getMissionActionsToCreateUpdateOrDelete
are well-aligned with the changes made to the function itself. These tests ensure that the function correctly handles the creation, update, or deletion of mission actions, which is essential for addressing the mission duplication issues. It's important to ensure comprehensive test coverage for all possible scenarios involving mission actions to maintain the application's reliability.frontend/src/features/Mission/components/MissionForm/index.tsx (3)
- 26-31: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
Consider reviewing the logic around debounced callbacks, such as
updateEditedActionFormValues
,removeAction
, andaddAction
, to ensure that potential race conditions are handled correctly. This is crucial for maintaining the reliability of asynchronous state updates, especially in a complex form handling scenario.
- 26-31: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
Monitor the component's performance, especially during form interactions, to identify potential bottlenecks. Given the complexity of the component and the extensive use of state and props, further optimizations may be necessary to ensure a smooth user experience, especially on slower devices.
- 26-31: > 📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
Review error handling strategies for external API calls to ensure they are comprehensive and user-friendly. While basic error handling is implemented, such as in the
toggleDeletionConfirmationDialog
function, ensuring a consistent approach across all external interactions will enhance the robustness of the component and improve the user experience.
import { assertNotNullish } from '@utils/assertNotNullish' | ||
import { getMissionStatus } from 'domain/entities/mission/utils' | ||
import { SideWindowMenuKey } from 'domain/entities/sideWindow/constants' | ||
import { omit } from 'lodash/fp' | ||
import { useCallback, useEffect, useMemo, useRef, useState } from 'react' | ||
import styled from 'styled-components' | ||
import { FrontendErrorBoundary } from 'ui/FrontendErrorBoundary' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]
Consider refactoring the MissionForm
component to improve maintainability and modularity. The component is large and handles multiple responsibilities, which could make future modifications more challenging. Breaking it down into smaller, more focused sub-components and separating business logic from UI rendering where possible would enhance readability and maintainability.
Quality Gate passedIssues Measures |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- frontend/cypress/e2e/side_window/mission_form/sea_control_edition.spec.ts (1 hunks)
Additional comments (1)
frontend/cypress/e2e/side_window/mission_form/sea_control_edition.spec.ts (1)
- 269-343: The added non-regression test is a valuable addition to ensure that mission actions IDs are correctly updated and not mistakenly modified during the update process. This test addresses a specific bug scenario described in the comments, which is crucial for maintaining data integrity in the application. However, there are a few areas that could be improved for clarity and maintainability:
Comments and Documentation: The comments explaining the bug scenario are clear and provide good context for the test. It's beneficial for future maintenance and understanding the purpose of the test.
Use of
cy.wait()
: The use ofcy.wait()
with hardcoded time values (e.g.,cy.wait(500)
) can lead to flaky tests, especially if the application's response times vary under different conditions. It's recommended to use more deterministic wait conditions, such ascy.wait('@alias')
for waiting on specific network requests to complete, which you've done in some parts of the test. Consider replacing or minimizing the use of hardcoded waits with more reliable synchronization methods.Hardcoded IDs: The test relies on hardcoded IDs (e.g.,
cy.intercept('PUT', '/bff/v1/mission_actions/4', {...}
). While this might be necessary for the test setup, it's worth considering if there's a way to make the test more dynamic or resilient to changes in data. If the IDs are expected to change or if the test data setup might vary, consider ways to retrieve or assert these dynamically.Duplication of Setup Code: There's some duplication in the setup code across tests, such as intercepting the same network requests and setting up the form. Consider refactoring common setup tasks into reusable functions or using
beforeEach
hooks where appropriate to reduce duplication and improve test maintainability.Overall, the test addition is a positive step towards ensuring the application's robustness against a specific bug scenario. Addressing the above points can further enhance the test's reliability and maintainability.
Linked issues
Summary by CodeRabbit