fix: last field overflow

[harshrajeevsingh]

Fixes: #7216

The issue was caused by the min-width property of StyledEditableCellEditModeContainer. So, I removed it.

[greptile-apps]

PR Summary

Fixed overflow issue in table cells by removing min-width property from StyledEditableCellEditModeContainer, allowing input fields to shift left instead of extending beyond screen boundaries.

• Modified packages/twenty-front/src/modules/object-record/record-table/record-table-cell/components/RecordTableCellEditMode.tsx to remove min-width constraint
• Potential concern: remaining min-width: 200px in StyledTableCellInput could still cause overflow issues

_{1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile}

[lucasbordeau]

@harshrajeevsingh This issue should be fixed by using the overflow detection mechanism from the library we use for dropdowns : floating-ui.

The trick is to tell the dropdown to watch for overflow against the main app container.

Try this :

flip({
        boundary: document.querySelector('#root') ?? undefined
      }),

In RecordInlineCellEditMode

[harshrajeevsingh]

Hey, @lucasbordeau Thanks for the input. I'm already familiar with this package since I solved many related issues earlier in this repo.
I think you are looking at the issue's image provided by Bonapara but the issue is a bit different now. You can see the issue more clearly here:
#7216 (comment)
Instead of overflowing out of the container, it stretches the table body.

I tried the code you provided above, but it didn't work. I think the issue is indeed happening due to the width of the StyledEditableCellEditModeContainer because that's the reference for the floating element: StyledTableCellInput.

Removing the excessive width larger than the inline cell makes the detection overflow work and the element is positioned based on the available viewport. Also, removing it won't cause any problem since StyledTableCellInput has the same min-width: 200px which keeps the same floating style wherever needed.

Screencast.from.2024-11-16.00-05-49.webm

[charlesBochet]

@lucasbordeau let's not forget this one :)