# Modal API Refactoring
This PR refactors the modal system to use an imperative approach for
setting hotkey scopes, addressing race conditions that occurred with the
previous effect-based implementation.
Fixes#11986Closes#12087
## Key Changes:
- **New Modal API**: Introduced a `useModal` hook with `openModal`,
`closeModal`, and `toggleModal` functions, similar to the existing
dropdown API
- **Modal Identification**: Added a `modalId` prop to uniquely identify
modals
- **State Management**: Introduced `isModalOpenedComponentState` and
removed individual boolean state atoms (like
`isRemoveSortingModalOpenState`)
- **Modal Constants**: Added consistent modal ID constants (e.g.,
`FavoriteFolderDeleteModalId`, `RecordIndexRemoveSortingModalId`) for
better maintainability
- **Mount Effects**: Created mount effect components (like
`AuthModalMountEffect`) to handle initial modal opening where needed
## Implementation Details:
- Modified `Modal` and `ConfirmationModal` components to accept the new
`modalId` prop
- Added a component-state-based approach using
`ModalComponentInstanceContext` to track modal state
- Introduced imperative modal handlers that properly manage hotkey
scopes
- Components like `ActionModal` and `AttachmentList` now use the new
`useModal` hook for better control over modal state
## Benefits:
- **Race Condition Prevention**: Hotkey scopes are now set imperatively,
eliminating race conditions
- **Consistent API**: Modal and dropdown now share similar patterns,
improving developer experience
## Tests to do before merging:
1. Action Modals (Modal triggered by an action, for example the delete
action)
2. Auth Modal (`AuthModal.tsx` and `AuthModalMountEffect.tsx`)
- Test that auth modal opens automatically on mount
- Verify authentication flow works properly
3. Email Verification Sent Modal (in `SignInUp.tsx`)
- Verify this modal displays correctly
4. Attachment Preview Modal (in `AttachmentList.tsx`)
- Test opening preview modal by clicking on attachments
- Verify close, download functionality works
- Test modal navigation and interactions
5. Favorite Folder Delete Modal (`CurrentWorkspaceMemberFavorites.tsx`)
- Test deletion confirmation flow
- Check that modal opens when attempting to delete folders with
favorites
6. Record Board Remove Sorting Modal (`RecordBoard.tsx` using
`RecordIndexRemoveSortingModalId`)
- Test that modal appears when trying to drag records with sorting
enabled
- Verify sorting removal works correctly
7. Record Group Reorder Confirmation Modal
(`RecordGroupReorderConfirmationModal.tsx`)
- Test group reordering with sorting enabled
- Verify confirmation modal properly handles sorting removal
8. Confirmation Modal (base component used by several modals)
- Test all variants with different confirmation options
For each modal, verify:
- Opening/closing behavior
- Hotkey support (Esc to close, Enter to confirm where applicable)
- Click outside behavior
- Proper z-index stacking
- Any modal-specific functionality
## What
- Deprecate overlayscrollbars as we decided to follow the native
behavior
- rework on performances (avoid calling recoil states too much at field
level which is quite expensive)
- Also implements:
https://github.com/twentyhq/core-team-issues/issues/569
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
This PR fixes a bug that prevented to do the matching of an imported CSV
file that contains a SELECT type column.
Fixes https://github.com/twentyhq/twenty/issues/11220
## Stacking context improvement
During the development it was clear that we lacked a reliable way to
understand our own z indices for components like modal, portaled
dropdown, overlay background, etc.
So in this PR we introduce a new enum RootStackingContextZIndices, this
enum allows to keep track of our root stacking context component
z-index, and because it is an enum, it prevents any conflict.
See
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_positioned_layout/Stacking_context
for reference.
## Component cleaning
Components have been reorganized in a SubMatchingSelectRow component
The Dropdown component has been used to replace the SelectInput
component which doesn't fit this use case because we are not in a cell,
we just need a simple standalone dropdown, though it would be
interesting to extract the UI part of the SelectInput, to share it here,
the benefit is not obvious since we already have good shared components
like Tag and Dropdown to implement this specific use case.
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
# Introduction
closes https://github.com/twentyhq/core-team-issues/issues/591
Same than for `twenty-shared` made in
https://github.com/twentyhq/twenty/pull/11083.
## TODO
- [x] Manual migrate twenty-website twenty-ui imports
## What's next:
- Generate barrel and migration script factorization within own package
+ tests
- Refactoring using preconstruct ? TimeBox
- Lint circular dependencies
- Lint import from barrel and forbid them
### Preconstruct
We need custom rollup plugins addition, but preconstruct does not expose
its rollup configuration. It might be possible to handle this using the
babel overrides. But was a big tunnel.
We could give it a try afterwards ! ( allowing cjs interop and stuff
like that )
Stuck to vite lib app
Closed related PRs:
- https://github.com/twentyhq/twenty/pull/11294
- https://github.com/twentyhq/twenty/pull/11203
Mostly renaming objects to avoid conflicts (it was painful because names
were too generic so you could cmd+replace easily)
Also refactoring `useBuildAvailableFieldsForImport`
# Introduction
In this PR we've migrated `twenty-shared` from a `vite` app
[libary-mode](https://vite.dev/guide/build#library-mode) to a
[preconstruct](https://preconstruct.tools/) "atomic" application ( in
the future would like to introduce preconstruct to handle of all our
atomic dependencies such as `twenty-emails` `twenty-ui` etc it will be
integrated at the monorepo's root directly, would be to invasive in the
first, starting incremental via `twenty-shared`)
For more information regarding the motivations please refer to nor:
- https://github.com/twentyhq/core-team-issues/issues/587
-
https://github.com/twentyhq/core-team-issues/issues/281#issuecomment-2630949682
close https://github.com/twentyhq/core-team-issues/issues/589
close https://github.com/twentyhq/core-team-issues/issues/590
## How to test
In order to ease the review this PR will ship all the codegen at the
very end, the actual meaning full diff is `+2,411 −114`
In order to migrate existing dependent packages to `twenty-shared` multi
barrel new arch you need to run in local:
```sh
yarn tsx packages/twenty-shared/scripts/migrateFromSingleToMultiBarrelImport.ts && \
npx nx run-many -t lint --fix -p twenty-front twenty-ui twenty-server twenty-emails twenty-shared twenty-zapier
```
Note that `migrateFromSingleToMultiBarrelImport` is idempotent, it's atm
included in the PR but should not be merged. ( such as codegen will be
added before merging this script will be removed )
## Misc
- related opened issue preconstruct
https://github.com/preconstruct/preconstruct/issues/617
## Closed related PR
- https://github.com/twentyhq/twenty/pull/11028
- https://github.com/twentyhq/twenty/pull/10993
- https://github.com/twentyhq/twenty/pull/10960
## Upcoming enhancement: ( in others dedicated PRs )
- 1/ refactor generate barrel to export atomic module instead of `*`
- 2/ generate barrel own package with several files and tests
- 3/ Migration twenty-ui the same way
- 4/ Use `preconstruct` at monorepo global level
## Conclusion
As always any suggestions are welcomed !
# Introduction
Avoid having multiple `isDefined` definition across our pacakges
Also avoid importing `isDefined` from `twenty-ui` which exposes a huge
barrel for a such little util function
## In a nutshell
Removed own `isDefined.ts` definition from `twenty-ui` `twenty-front`
and `twenty-server` to move it to `twenty-shared`.
Updated imports for each packages, and added explicit dependencies to
`twenty-shared` if not already in place
Related PR https://github.com/twentyhq/twenty/pull/9941
Issue #6976
@FelixMalfait
I could not do
```
import { Banner } from 'twenty-ui';
const StyledBanner = styled(Banner)
display: flex;
align-items: center;
padding: ${({ theme }) => theme.spacing(8)};
position: absolute;
border-radius: 8px;
&:hover {
background-color: ${({ theme }) => theme.accent.primary};
}
;
```
The styles wont get overridden for Banner, so for now I styled a new
banner in `UnmatchColumnBanner` which is inconsistent.
I couldnt figure out why css properties are not being overridden, need
help!
@Bonapara
Question -
Should the click work on entire banner or just cheveron? For now it just
on cheveron click.
https://github.com/user-attachments/assets/0f409e78-a341-4f26-af74-117e4b2775a9
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
### Description:
- we move all logic about the unmatchedOptions to a new component called
UnmatchColumn, because as it will be a full line in the table, it was
better to update where the component will be rendered
- In the latest changes to keep the columns when we change the step to
step 3 and go back to step 2, we added a fallback state
initialComputedColumnsState that saves the columns and only reverts the
updates when we go back to step 1 or close by clicking the X button
### Refs:
#6135
```
It was necessary to add references and floating styles to the generic component to fix the bug when the last option was open and the dropdown was being hidden in the next row of the spreadsheet table. We fixed the same problem that occurs in the companies table as well
```
we used this approach mentioned on this documentation to be able to use
the hook without calling it on each component, we are calling only once,
on the shared component
<https://floating-ui.com/docs/useFloating#elements>\
before:
now:
###
Demo: <https://jam.dev/c/e0e0b921-7551-4a94-ac1c-8a50c53fdb0c>
Fixes#6135
NOTES: the enter key are not working on main branch too
---------
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Hi @Bonapara,
Issue #6385
I encountered an issue with the Modal component where its width was
fixed at 400px. While the container housing the Modal adjusted its size
based on the screen width, the Modal itself remained at 400px regardless
of the screen size.
I have implemented a change to address this problem. Could you please
review the changes and let me know your thoughts?
Thank you!
https://github.com/user-attachments/assets/8358aacb-d6c3-440e-895e-7abc4f8a3534
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Adding support for all Composite Fields while using the "import"
functionality. This includes:
- Currency
- Address
Edit :
- Refactored a lot of types in the spreadsheet import module
- Renamed a lot of functions, hooks and types that were not
self-explanatory enough
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
This is a small PR to improve the design of our CSV import.
I noticed the back button that was implemented in a recent PR #5625 was
broken and would need to be fixed (e.g. try to come back to the very
first upload step from the sheet selection step). cc @shashankvish0010
if you want to give a stab at fixing your PR that'd be amazing, thanks!
Users now can make a back transition from the current step state.
- Added a `BackButton` component to `spreadsheet-import` in order to use
it within the step state components.
- Used the prebuilt `prevStep` from `useStepBar` and passed it as a prop
to the `Uploadflow` to get the previous state as activestep.
- Added a `previousState` to set the previous state with the required
key data.
- Added a `handleOnBack` function in `Uploadflow` to set the correct
state and call the `prevStep` function to make the transition.
- Added a callback function `onBack` and passed it as props to each step
state component.
fixes: #5564https://github.com/twentyhq/twenty/assets/140178357/be7e1a0a-0fb8-41f2-a207-dfc3208ca6f0
---------
Co-authored-by: Thomas Trompette <thomas.trompette@sfr.fr>
Some parts of the Frontend used theme constants exported from
`modules/ui` while other parts used theme constants exported from
`twenty-ui`.
This PR centralizes theme constants by removing them from `modules/ui`
completely.
