## Remove Recoil from twenty-ui
Completely removes the `recoil` dependency from `twenty-ui` by
converting all atoms, hooks, and providers to Jotai equivalents.
### twenty-ui
- `createState` now returns a Jotai `PrimitiveAtom` instead of a Recoil
atom
- `iconsState`, `IconsProvider`, `useIcons` converted to Jotai
(`useSetAtom`, `useAtomValue`)
- `RecoilRootDecorator` now uses Jotai `Provider` (name kept for compat)
- Deleted unused `invalidAvatarUrlsState` (Avatar already uses
`invalidAvatarUrlsAtomV2`)
- Removed `recoil` from `package.json`
### twenty-front
- Created local Recoil `createState` at
`@/ui/utilities/state/utils/createState` for ~112 state files still on
Recoil
- Updated all imports accordingly
- Removed `iconsState` from Recoil snapshot preservation in `useAuth`
(lives in Jotai store now)
# What this PR does
This PR introduces what’s needed to progressively refactor the
useDropdown hooks we have.
It removes useDropdownV2 and renames useDropdown used for multi-page
dropdowns to useDropdownContextStateManagement
## The 3 useDropdown hooks
There are currently 3 useDropdown hooks :
One is used for managing states in some dropdowns that have multiple
inner pages with contexts and without recoil. It is limited and would
need a separate refactoring, thus I just renamed it.
Then we have useDropdown and useDropdownV2, which followed our multiple
versions of recoil state management wrappers.
Now that the state management has been stabilized, we can merge
everything on the last version.
## What this refactor will allow next
This refactor will allow to refactor the legacy recoil state management,
because useDropdown is depending on legacy recoil states with scopeId.
Because there are only a dozen of those legacy states left, and the
dropdown’s ones are the harder to refactor, because swapping them as-is
causes a big QA, and if we have a big QA to do on all dropdowns, better
refactor the whole dropdown management and have everything clean.
After this refactor, we will be able to delete the legacy dropdown
states, and proceed with the other legacy states, then removing all the
legacy recoil state mangament.
## How do we allow progressive refactoring ?
There are many places where useDropdown is used.
To have an easier refactoring process, we want to merge multiple small
pull requests so that it is easier to QA and review.
For this we will maintain both legacy component state and component
state V2 in parallel for isDropdownOpen, so that the new hooks
`useOpenDropdown` , `useCloseDropdown` are doing the same thing than
`useDropdown` and `useDropdownV2` .
Thus for the moment, whether we use the legacy hooks or the new ones,
the effects are the same.
And we can have dropdowns operating on the old states and the new states
living side by side in the app.
## QA
Component | Status | Comments
-- | -- | --
CommandMenuActionMenuDropdown | Ok |
RecordIndexActionMenuDropdown | Ok |
RecordShowRightDrawerOpenRecordButton | Ok |
useCloseActionMenu | Ok |
CommandMenuContextChipGroups | Ok |
useCommandMenuCloseAnimationCompleteCleanup | Ok |
ObjectOptionsDropdown | Ok |
ObjectOptionsDropdownContent | Ok |
ObjectOptionsDropdownFieldsContent | Ok |
ObjectOptionsDropdownHiddenFieldsContent | Ok |
ObjectOptionsDropdownHiddenRecordGroupsContent | Ok |
ObjectOptionsDropdownLayoutContent | Ok |
ObjectOptionsDropdownLayoutOpenInContent | Ok |
ObjectOptionsDropdownMenuContent | Ok |
ObjectOptionsDropdownRecordGroupFieldsContent | Ok |
ObjectOptionsDropdownRecordGroupsContent | Ok |
ObjectOptionsDropdownRecordGroupSortContent | Ok |
RecordBoardColumnHeaderAggregateDropdown | Ok |
AggregateDropdownContent | Ok |
RecordBoardColumnHeaderAggregateDropdownFieldsContent | Ok |
RecordBoardColumnHeaderAggregateDropdownMenuContent | Ok |
RecordBoardColumnHeaderAggregateDropdownMenuContent | Ok |
RecordBoardColumnHeaderAggregateDropdownOptionsContent | Ok |
RecordBoard | Ok | Used closeAnyOpenDropdown instead for a better UX
RecordBoardCard | Ok |
useRecordBoardSelection | Ok |
RecordTableColumnAggregateFooterDropdownContent | Ok |
RecordTableColumnFooterWithDropdown | Ok |
useOpenRecordFilterChipFromTableHeader | Ok |
useCloseAnyOpenDropdown | Ok |
useCloseDropdownFromOutside | Removed | Removed because unused
useDropdownV2 | Removed | Removed because all calls have been removed
useOpenDropdownFromOutside | Removed | Removed because unused
useCloseAndResetViewPicker | Ok |
WorkflowVariablesDropdown | Ok |
# 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
Charles Bochet