Closes#12361
### Changes Made
- In `ActivityTargetsInlineCell`, we now use different component
instance IDs based on context. This ensures that each instance of the
component (whether in right drawer or main view) has its own isolated
state, preventing state conflicts and duplicate dropdowns.
- The `MultipleRecordPicker` component now properly resets its state
when closed, preventing state leakage between instances.
https://github.com/user-attachments/assets/deb99687-a803-417e-a339-cab061026739
# Introduce focus stack to handle hotkeys
This PR introduces a focus stack to track the order in which the
elements are focused:
- Each focused element has a unique focus id
- When an element is focused, it is pushed on top of the stack
- When an element loses focus, we remove it from the stack
This focus stack is then used to determine which hotkeys are available.
The previous implementation lead to many regressions because of race
conditions, of wrong order of open and close operations and by
overwriting previous states. This implementation should be way more
robust than the previous one.
The new api can be incrementally implemented since it preserves
backwards compatibility by writing to the old hotkey scopes states.
For now, it has been implemented on the modal components.
To test this PR, verify that the shortcuts still work correctly,
especially for the modal components.
This PR fixes the infinite loop that was happening in `RecordShowEffect`
component due to a useEffect on `recordStoreFamilyState` which was
creating a non-deterministic open loop.
The fix was to use a recoilCallback to avoid reading a stale state from
Recoil with `useRecoilValue`, useRecoilCallback always gets the most
fresh data and commits everything before React goes on with rendering,
thus avoiding any stale value in a useEffect.
Fixes https://github.com/twentyhq/twenty/issues/11079
Fixes https://github.com/twentyhq/core-team-issues/issues/957
Remove FieldContext hotkey scope as:
- each Field should set its own hotkey scope (ex:
emails-field-input-{recordId} or emails-field-input for now)
- while opening a fieldInput, we should synchronously set the
corresponding hotkey scope
To cut this refactoring in half, I'm allowing all input to use
TableHotkeyScope.CellEditMode
## 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>
# 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
In this PR:
- Remove deactivated objects from ActivityTargetInlineCell record picker
- Prevent users to deactivate createdAt, updatedAt, deletedAt fields on
any objects
Still left:
- write unit tests on the assert utils
- write integration tests on field metadata service
- prevent users to deactivate createdAt, updatedAt, deletedAt on FE
# 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 !
Closes https://github.com/twentyhq/core-team-issues/issues/271
This PR
- Removes the feature flag IS_COMMAND_MENU_V2_ENABLED
- Removes all old Right drawer components
- Removes the Action menu bar
- Removes unused Copilot page
Refactor to only have MultipleRecordPicker and SingleRecordPicker
What's done:
- SingleRecordPicker, MultipleRecordPicker
- RelationToOneInput
- RelationFromManyInput
- usage in TableCell, InlineCell, RelationDetailSection, Workflow
What's left:
- Make a pass on the app, to make sure the hotkeyScopes, clickOutside
are properly set
- Fix flashing on ActivityTarget
- add more tests on the code
## Context
ActivityTargetsInlineCell was not using the useIsFieldValueReadOnly hook
but a dedicated prop instead. To align with the rest of the
implementation I've updated that part of the code however we still want
the table/kanban views to always be in read-only mode regardless of the
hook logic so I've updated the hook to take the ContextStoreViewType
into account.
This PR is part 3 of RecordPicker refactoring.
It aims to remove all effects from:
- (low level layer) SingleRecordPicker, MultipleRecordPicker
- (higher level layer) RelationPicker, RelationToOneInput,
RelationFromManyInput, ActivityTargetInput...
In this PR, I'm re-grouping Effects in ActivityTarget section and
creating a hook that will be called on inlineCellOpen
## Context
We are experiencing a lot of re-rendering / flash on MultiRecordSelect /
SingleRecordSelect / RelationPicker.
This PR is a first step to refactor this components
## Scope
Only move files to uniformize and prepare for the upcoming refactoring
## Vision
- SingleRecordPicker
- MultipleRecordPicker
- sharing RecordPicker tooling (RecordPickerComponentInstanceContext,
searchState)
Used in other areas:
- RelationPicker (which is actually only a subcomponent of
RelationToOneFieldInput)
- RelationFromManyFieldInput
- WorkflowRelationFieldInput
- etc.
+ remove all effects
+ migrate to the latest APIs
+ make a pass on re-renders to remove them completely (we likely need to
use a bit more familyStates here)
# Introduction
This PR is highly related to previous optimistic cache refactor:
https://github.com/twentyhq/twenty/pull/9881
Here we've added some logic within the
`triggerUpdateRelationsOptimisticEffect` which will now run if given
recordInput `deletedAt` field is defined.
If deletion, we will iterate over all the fields searching for
`RELATION` for which deletion might implies necessity to detach the
relation
## Known troubleshooting ( also on main )
We might have to refactor the `prefillRecord` to spread and
overrides`inputValue` over defaultOne as inputValue could be a partial
one for more info please a look to
# Conclusion
Any suggestions are welcomed !
fixes https://github.com/twentyhq/twenty/issues/9580
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- Removed disableBlur property from dropdown because it is no longer
needed since there's only one OverlayContainer component so there can be
only one blur at a time.
- Removed blur CSS properties from every component that used it because
one standalone OverlayContainer is able to handle all cases if placed
properly.
- Also removed disableBackgroundBlur property from SingleRecordSelect
- Removed FieldInputOverlay and FieldTextAreaOverlay components that
were a first attempt to create something like an OverlayContainer
- Used new unified OverlayContainer in RecordInlineCell and
RecordTableCell
- Fixed ScrollWrapper so that it works well both for dropdown with non
overflowing content and dropdown with overflowing content.
- Removed export default value on SearchVariablesDropdown as it is not
used in this codebase
- Refactored SearchVariablesDropdown function as component anti-pattern
- Refactored SearchVariablesDropdownFieldItems UI problems with
separator and missing ScrollWrapper behavior
- Refactored SearchVariablesDropdownObjectItems with UI problems with
separator and missing ScrollWrapper behavior
- Fixed blur bug on Firefox due to wrong placement of the element that
had the CSS property. Blur works on Firefox it it's on the container
that has the highest level in the tree.
- Fixed bug in ActivityTargetInlineCell by removing an unnecessary
container component StyledSelectContainer
- Unified problems of field height with a new common component
FieldInputContainer, instead of putting width and height at the wrong
abstraction level, width and height are a field's concern not a
dropdown, overlay or low-level input concern.
- Fixed block editor dropdown with new OverlayContainer
- Aligning field dropdown with their anchor on inline and table cells,
there are still many small pixel misalignments that give a low quality
impression.
- Fixed FormDateFieldInput that was missing OverlayContainer
This PR is fixing the Task/Note Target picker.
## Issue
A few weeks ago, we have simplified the recordPicker logic. During this
refacto, we stopped making sure the selected records were fetched.
However, the optimistic update of the activity supposed that current
activityTargets are present in the selection in the picker in order to
filter out the removed items.
## Fix
In case we don't find the record in the picker selection, we don't
filter it out (it means the user cannot have removed it)
## Next step
@ijreilly I think we should put it back, as the selected records do not
appear on top anymore
- Rename all parts using the name "relation" to "record" when component
is only selecting record
- Remove the use of scope states in folder
- Rename entities to records
This PR prepares the use of the record picker in workflows
Simplifying the logic around multi-object pickers and search by getting
rid of the behaviour that keeped selected elements even when they did
not match the search filter (eg keeping selected record "Brian Chesky"
in dropdown even when search input is "Qonto"). This allows us to
simplify the fetch queries around the search to only do one query.
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
[This PR](https://github.com/twentyhq/twenty/pull/8210) introduced a
regression, causing noteId or taskId (respectively for noteTarget or
taskTarget creation) to be overwritten with an undefined value in the
input for noteTarget or taskTarget creation.
This is because in ActivityTargetInlineCellEditMode, in addition to the
noteId and taskId we are declaring, we are looking into the object
(noteTarget or taskTarget)'s fields and prefilling the record-to-create
with a value, potentially undefined, for all of the object fields.
So when looping over noteTarget's fields, we would find the `note`
relation field, and eventually add `note: undefined` to the
record-to-create input, in addition to the non-empty and valid existing
`noteId`.
Then in sanitizeRecordInput, from the note added right above, we add an
empty noteId to the input from node, overwriting the "good" noteId.
There are several ways to fix this, I chose to update prefillRecord not
to add an empty "note" object that makes no sense in addition to the
"noteId" we already have at this stage.
It is also possible to update `sanitizeRecordInput` not to overwrite a
value from a relation (noteId from note relation) if there is already a
value in the input.
Fixes [#6335](https://github.com/twentyhq/twenty/issues/6335)
This pull request is for issue
[#6335](https://github.com/twentyhq/twenty/issues/6335): Refactor
RecordInlineCell tree with a Context to avoid props drilling. For the
refactoring, this PR made changes as below:
- Created new script RecordInlineCellContext.tsx: Defining a context to
pass in useContext()
- Updated RecordInlineCell.tsx: Passing the necessary props as context
values, wrapping with RecordInlineCellContext.Provider
- Updated RecordInlineCellContainer.tsx: Passing the props to
RecordInlineContainer as RecordInlineCellContext
- Updated RecordInlineCellDisplayMode.tsx: retrieves values from
useRecordInlineCellContext instead of directly assigning them
- RecordInlineCellValue.tsx: Removed values passed through
<RecordInlineCellDisplayMode> as they are now retrieved through
useRecordInlineCellContext + Removed the null check for
RecordInlineCellContextProps.
Using RecordInlineCellContext, I believe the context goes to the top of
the hierarchy and passed to the required layers without going through
several layers. However, please let me know if I understood the issue
incorrectly or it is not solved properly.
Thank you in advance for your review!
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Closes#5924.
Adding the "many" side of relations in the table view, and fixing some
issues (glitch in Multi record select, cache update after update).
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
In this PR, we implement the display and update of fields from
fromManyObjects (e.g update Employees for a Company).
Product requirement
- update should be triggered at each box check/uncheck, not at lose of
focus
Left to do in upcoming PRs
- add the column in the table views (e.g. column "Employees" on
"Companies" table view)
- add "Add new" possibility when there is no records (as is currently
exists for "one" side of relations:)
<img width="374" alt="Capture d’écran 2024-06-10 à 17 38 02"
src="https://github.com/twentyhq/twenty/assets/51697796/6f0cc494-e44f-4620-a762-d7b438951eec">
- update cache after an update affecting other records (e.g "Listings"
have one "Person"; if listing A belonged to Person A but then we
attribute listing A to Person B, Person A is no longer owner of Listing
A. For the moment that would not be reflected immediatly leading, to
potential false information if information is accessed from cache)
- try to get rid of the glitch - we also have it on the task page
example. (probably) due to the fact that we are using a recoil state to
read, update then re-read
https://github.com/twentyhq/twenty/assets/51697796/54f71674-237a-4946-866e-b8d96353c458
## Context
Fixing `setIsFocused is not a function` and the fact that edit buttons
were not showing up anymore.
A new FieldFocusContextProvider has been introduced and added to
RecordInlineCell but not ActivityTargetsInlineCell. This should fix the
issue.
<img width="523" alt="Screenshot 2024-06-05 at 17 42 07"
src="https://github.com/twentyhq/twenty/assets/1834158/1c1f919e-3829-4e40-b573-3b1b75b7c16f">
This PR introduces many improvements over the new profiling story
feature, with new tests and some refactor with main :
- Added use-context-selector for getting value faster in display fields
and created useRecordFieldValue() hook and RecordValueSetterEffect to
synchronize states
- Added performance test command in CI
- Refactored ExpandableList drill-downs with FieldFocusContext
- Refactored field button icon logic into getFieldButtonIcon util
- Added RelationFieldDisplay perf story
- Added RecordTableCell perf story
- First split test of useField.. hook with useRelationFieldDisplay()
- Fixed problem with set cell soft focus
- Isolated logic between display / soft focus and edit mode in the
related components to optimize performances for display mode.
- Added warmupRound config for performance story decorator
- Added variance in test reporting
When writing to the normalized cache (record), it's crucial to use _refs
for relationships to avoid many problems. Essentially, we only deal with
level 0 and generate all fields to be comfortable with their defaults.
When writing in queries (which should be very rare, the only cases are
prefetch and the case of activities due to the nested query; I've
reduced this to a single file for activities
usePrepareFindManyActivitiesQuery 🙂), it's important to use queryFields
to avoid bugs. I've implemented them on the side of query generation and
record generation.
When doing an updateOne / createOne, etc., it's necessary to distinguish
between optimistic writing (which we actually want to do with _refs) and
the server response without refs. This allows for a clean write in the
optimistic cache without worrying about nesting (as the first point).
To simplify the whole activities part, write to the normalized cache
first. Then, base queries on it in an idempotent manner. This way,
there's no need to worry about the current page or action. The
normalized cache is up-to-date, so I update the queries. Same idea as
for optimisticEffects, actually.
Finally, I've triggered optimisticEffects rather than the manual update
of many queries.
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Abdul Rahman