Saving view doesn't work as expected

[BOHEUS]

Scenario 1:

1. Log in
2. Go to Companies
3. Create new view
4. Apply filter in new view and save

Actual: Button must be clicked twice in order to save the filter

Expected: Filter should be saved after clicking the button once

Scenario 2:

1. Log in
2. Go to Companies
3. Create new view
4. Apply filter in new view and save
5. Remove applied filter and save

Actual: "Update view" button stays even though request to backend is sent and view isn't updated

Expected: View is updated and button disappears

https://github.com/twentyhq/private-issues/issues/461

[sonarly]

🟡 Sonarly Analysis — Medium Severity

View save lacks optimistic local state update, relies solely on async SSE

After saving view filters/sorts, the local metadata store is not updated optimistically — it waits for an asynchronous SSE event round-trip from the backend, causing the "Update view" button to remain visible and requiring a second click.

Root Cause

The "Update view" button visibility is controlled by canShowButton in UpdateViewButtonGroup.tsx (line 95-100), which compares the current view's filters (from the metadata store) against the active record filters (from Jotai component state):

const canShowButton =
    (viewFiltersAreDifferentFromRecordFilters ||
      viewSortsAreDifferentFromRecordSorts ||
      viewFilterGroupsAreDifferentFromRecordFilterGroups ||
      viewAnyFieldFilterDifferentFromCurrentAnyFieldFilter) &&
    !hasFiltersQueryParams;

The viewFiltersAreDifferentFromRecordFilters hook (useAreViewFiltersDifferentFromRecordFilters.ts) derives the view's filters from useGetCurrentViewOnly() → viewFromViewIdFamilySelector → viewsSelector → metadataStoreState('viewFilters').current.

When "Update view" is clicked, saveCurrentViewFilterAndSorts() fires GraphQL mutations (CreateViewFilter, UpdateViewFilter, DeleteViewFilter) via usePerformViewFilterAPIPersist. These mutations do not include any optimistic update to the local metadataStoreState. The mutations have no optimisticResponse, no cache update callback, and no direct store mutation.

The only path for updating metadataStoreState.viewFilters.current is:

1. Backend processes the mutation
2. Backend emits SSE metadata event via the onEventSubscription GraphQL subscription
3. Frontend receives the SSE event in useTriggerEventStreamCreation
4. Event is dispatched as a browser custom event via dispatchMetadataOperationBrowserEvent
5. MetadataStoreSSEEffect catches it and calls addToDraft() / removeFromDraft()
6. applyChanges() promotes draft to current

This SSE round-trip introduces latency. When the user clicks "Update view":

• The mutation succeeds (backend is updated)
• But metadataStoreState.viewFilters.current still has the old filter data
• The diff check still finds differences → button stays visible
• Only after the SSE event arrives and is applied does current update → button disappears

Scenario 1 (double-click): First click fires mutations, SSE arrives ~100-500ms later updating the store. If the user clicks again before SSE arrives, the second click finds the diff still exists and fires redundant mutations. Once SSE arrives, the button disappears.

Scenario 2 (remove filter, button stays): When deleting a filter, the DeleteViewFilter mutation fires, but metadataStoreState.viewFilters.current still contains the deleted filter. The SSE delete event needs to arrive and removeFromDraft + applyChanges must complete before the store reflects the deletion.

This architecture was introduced in commits ba9aa41bba (metadata store cleanup, SSE unification — March 16, 2026) and 5c745059ad (remove converter layer — same day), which moved views to be sourced entirely from the SSE-updated metadata store with no optimistic local updates after mutations. Before these refactors, there was a converter layer that may have allowed more direct state management.

Fix approach: After the mutations in useSaveRecordFiltersToViewFilters succeed, optimistically update metadataStoreState('viewFilters') using the addToDraft / removeFromDraft / applyChanges pattern from useUpdateMetadataStoreDraft. This would immediately update metadataStoreState.viewFilters.current, causing viewsSelector to reflect the new state and canShowButton to return false. The same fix should be applied to useSaveRecordSortsToViewSorts, useSaveRecordFilterGroupsToViewFilterGroups, and useSaveAnyFieldFilterToView.

Blame commit: ba9aa41b by charlesBochet — refactor: metadata store cleanup, SSE unification, mock metadata loading & login redirect fix (#18651)

Suggested Fix

After each view save hook's mutations succeed, the metadata store (metadataStoreState) is now optimistically updated to reflect the new state immediately. This eliminates the dependency on the SSE round-trip for UI state reconciliation.

What changed in each file:

1. useSaveRecordFiltersToViewFilters.ts — After all create/update/delete filter mutations succeed, replaces the viewFilters entries in metadataStoreState.current for the current view with the computed newViewFilters.

2. useSaveRecordSortsToViewSorts.ts — Same pattern for viewSorts entries.

3. useSaveRecordFilterGroupsToViewFilterGroups.ts — Same pattern for viewFilterGroups entries.

4. useSaveAnyFieldFilterToView.ts — After the view update mutation succeeds, updates the anyFieldFilterValue field on the current view in the views metadata store entry.

Each optimistic update:

• Reads the current state from the metadata store (respecting draft-pending status)
• Filters out entries belonging to the current view
• Replaces them with the new computed values
• Writes directly to .current so the viewsSelector (which reads .current) immediately reflects the saved state

When the SSE event arrives later, the addToDraft/applyChanges pipeline will find the data already matches and skip unnecessary updates due to isDeeplyEqual checks.

---

Analyzed by Sonarly · View full analysis