diff --git a/packages/twenty-front/src/modules/apollo/optimistic-effect/utils/triggerUpdateRecordOptimisticEffect.ts b/packages/twenty-front/src/modules/apollo/optimistic-effect/utils/triggerUpdateRecordOptimisticEffect.ts index 97284ab2be3c..3c09c213f68b 100644 --- a/packages/twenty-front/src/modules/apollo/optimistic-effect/utils/triggerUpdateRecordOptimisticEffect.ts +++ b/packages/twenty-front/src/modules/apollo/optimistic-effect/utils/triggerUpdateRecordOptimisticEffect.ts @@ -39,7 +39,7 @@ export const triggerUpdateRecordOptimisticEffect = ({ fields: { [objectMetadataItem.namePlural]: ( rootQueryCachedResponse, - { DELETE, readField, storeFieldName, toReference }, + { readField, storeFieldName, toReference }, ) => { const shouldSkip = !isObjectRecordConnectionWithRefs( objectMetadataItem.nameSingular, @@ -64,7 +64,6 @@ export const triggerUpdateRecordOptimisticEffect = ({ const rootQueryFilter = rootQueryVariables?.filter; const rootQueryOrderBy = rootQueryVariables?.orderBy; - const rootQueryLimit = rootQueryVariables?.first; const shouldTryToMatchFilter = isDefined(rootQueryFilter); @@ -123,56 +122,6 @@ export const triggerUpdateRecordOptimisticEffect = ({ }); } - const shouldLimitNextRootQueryEdges = isDefined(rootQueryLimit); - - // TODO: not sure that we should trigger a DELETE here, as it will trigger a network request - // Is it the responsibility of this optimistic effect function to delete a root query that will trigger a network request ? - // Shouldn't we let the response from the network overwrite the cache and keep this util purely about cache updates ? - // - // Shoud we even apply the limit at all since with pagination we cannot really do optimistic rendering and should - // wait for the network response to update the cache - // - // Maybe we could apply a merging function instead and exclude limit from the caching field arguments ? - // Also we have a problem that is not yet present with this but may arise if we start - // to use limit arguments, as for now we rely on the hard coded limit of 60 in pg_graphql. - // This is as if we had a { limit: 60 } argument in every query but we don't. - // so Apollo correctly merges the return of fetchMore for now, because of this, - // but wouldn't do it well like Thomas had the problem with mail threads - // because he applied a limit of 2 and Apollo created one root query in the cache for each. - // In Thomas' case we should implement this because he use a hack to overwrite the first request with the return of the other. - // See: https://www.apollographql.com/docs/react/pagination/cursor-based/#relay-style-cursor-pagination - // See: https://www.apollographql.com/docs/react/pagination/core-api/#merging-queries - if (shouldLimitNextRootQueryEdges) { - // If previous edges length was exactly at the required limit, - // but after update next edges length is under the limit, - // we cannot for sure know if re-fetching the query - // would return more edges, so we cannot optimistically deduce - // the query's result. - // In this case, invalidate the cache entry so it can be re-fetched. - const rootQueryCurrentCachedRecordEdgesLengthIsAtLimit = - rootQueryCurrentEdges.length === rootQueryLimit; - - // If next edges length is under limit, then we can wait for the network response and merge the result - // then in the merge function we could implement this mechanism to limit the number of edges in the cache - const rootQueryNextCachedRecordEdgesLengthIsUnderLimit = - rootQueryNextEdges.length < rootQueryLimit; - - const shouldDeleteRootQuerySoItCanBeRefetched = - rootQueryCurrentCachedRecordEdgesLengthIsAtLimit && - rootQueryNextCachedRecordEdgesLengthIsUnderLimit; - - if (shouldDeleteRootQuerySoItCanBeRefetched) { - return DELETE; - } - - const rootQueryNextCachedRecordEdgesLengthIsAboveRootQueryLimit = - rootQueryNextEdges.length > rootQueryLimit; - - if (rootQueryNextCachedRecordEdgesLengthIsAboveRootQueryLimit) { - rootQueryNextEdges.splice(rootQueryLimit); - } - } - return { ...rootQueryConnection, edges: rootQueryNextEdges,