Follow up on FieldInput fix #16611
Follow up on FieldInput fix #16611
Conversation
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
| const handleSubmitChanges = () => { | ||
| const { isValid, updatedItems } = validateInputAndComputeUpdatedItems(); | ||
| if (!isValid) { | ||
| return; | ||
| } | ||
|
|
||
| onChange(updatedItems); | ||
| }; |
There was a problem hiding this comment.
Bug: The MultiItemFieldInput component fails to reset its local state (e.g., isInputDisplayed) after submitting a new item, causing the input field to remain visible incorrectly.
Severity: HIGH | Confidence: High
🔍 Detailed Analysis
In the MultiItemFieldInput component, a refactoring removed the logic that resets the component's local state after an item is successfully submitted. Specifically, the setIsAddingNewItem(false) and setIsInputDisplayed(false) calls are missing from the handleEnter and handleSubmitChanges functions. Because isInputDisplayed and isAddingNewItem are managed by useState, they persist after submission. This causes the UI to remain in an editing state, with the input field still visible, instead of returning to its normal display state after the user adds an item.
💡 Suggested Fix
Restore the state reset logic within the handleEnter and handleSubmitChanges functions in the MultiItemFieldInput component. After a successful submission, call setIsAddingNewItem(false) and setIsInputDisplayed(false) to clean up the component's state and correctly update the UI.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location:
packages/twenty-front/src/modules/object-record/record-field/ui/meta-types/input/components/MultiItemFieldInput.tsx#L190-L197
Potential issue: In the `MultiItemFieldInput` component, a refactoring removed the logic
that resets the component's local state after an item is successfully submitted.
Specifically, the `setIsAddingNewItem(false)` and `setIsInputDisplayed(false)` calls are
missing from the `handleEnter` and `handleSubmitChanges` functions. Because
`isInputDisplayed` and `isAddingNewItem` are managed by `useState`, they persist after
submission. This causes the UI to remain in an editing state, with the input field still
visible, instead of returning to its normal display state after the user adds an item.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 7601312
Follow up on #16603