In this huge (sorry!) PR:
- introducing objectMetadataItem in contextStore instead of
objectMetadataId which is more convenient
- splitting some big hooks into smaller parts to avoid re-renders
- removing Effects to avoid re-renders (especially onViewChange)
- making the view prefetch separate from favorites to avoid re-renders
- making the view prefetch load a state and add selectors on top of it
to avoir re-renders
As a result, the performance is WAY better (I suspect the favorite
implementation to trigger a lot of re-renders unfortunately).
However, we are still facing a random app freeze on view creation. I
could not investigate the root cause. As this seems to be already there
in the precedent release, we can move forward but this seems a urgent
follow up to me ==> EDIT: I've found the root cause after a few ours of
deep dive... an infinite loop in RecordTableNoRecordGroupBodyEffect...
prastoin edit: close https://github.com/twentyhq/twenty/issues/10253
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Co-authored-by: prastoin <paul@twenty.com>
This PR implements a first real use case, now currentRecordFilters
component state acts as the global record filter reference.
It is set by the view initially and can be reset to view filters state
at any point.
This new state is also modified by two new upsertRecordFilter /
removeRecordFilter hooks that will be drop-in replacement of the actual
upsertCombinedViewFilter and removeCombinediewFilter hooks.
This PR implements the logic to manipulate record filters but only reads
it to make the table find many request, all other features are still
relying on the old view filter implementation.
Advanced filters are ignored because they are hidden and because this
effort is made precisely to allow the completion of the advanced filters
feature.
Fix#8757
This PR is adding the Add new button on view groups.
Also this PR fix an issue where the pending record can be draggable, and
is causing error.
<img width="1119" alt="Screenshot 2024-12-10 at 4 24 43 PM"
src="https://github.com/user-attachments/assets/4fd01e99-c85e-4a06-a733-cbf3cc32957d">
It also start to issues with the way we're using Context.
We're initializing pretty much all Context like this:
```typescript
export const RecordTableContext = createContext<RecordTableContextProps>(
{} as RecordTableContextProps,
);
```
This is causing issues when by mistake we use the context like this
outside the Provider hierarchy:
```typescript
const context = useContext(RecordTableContext);
```
This is going to fail silently, and all the context variables become
undefined...
To fix this I've introduced an util called `createRequiredContext`, this
one is returning an array containing the provider and the hook to
retrieve the context.
The context is initialized to undefined inside this utility, this way we
can check if the value has been initialized with the provider to check
if we're inside it. It'll throw an error if this one is used outside the
provider.
The return values are properly typed, so `undefined` is not added to the
value of the Context.
I'll create a followup ticket to use this new utility function, if
that's ok and replace it everywhere in the codebase.
We can also consider adding a eslint rule to warn about the use of
`createContext` directly.
This PR refactors the view module to implement utils that avoid having
to create hooks to inject the scope id in the states, like
`useViewStates`, each componentState will know its unique related
InstanceContext (which holds the instanceId), and thus will be able to
retrieve it itself.
We keep the naming componentState as it reflects the fact that those
states are tied to instances of a component (or its children).
We introduce the instance word where it is needed, in place of scopeId
for example, to precise the fact that we handle instances of component
state, one for each instance of a component.
For example, the currentViewId is a state that is tied to an instance of
the ViewBar, but as we can switch between views, we want currentViewId
to be a componentState tied to an instance of the ViewBar component.
This PR also refactors view filter and sort states to fix this issue :
https://github.com/twentyhq/twenty/issues/6837 and other problems
involving resetting those states between page navigation.
Fixes https://github.com/twentyhq/twenty/issues/6837
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
* Migrate record table to scope map
* Update record scope id to record id
* Remove todos and fix edit mode
* Fix perf
* Fix tests
* Fix tests
---------
Co-authored-by: Thomas Trompette <thomast@twenty.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
