Restore permission change detection in useFetchChatData

[ManojPawar2]

Overview

fetchAndSetPermissions in packages/react/src/hooks/useFetchChatData.js is designed to fetch permissions and only rebuild and re-apply them when they have actually changed since the last fetch. That optimization was silently
broken — the change-detection guard could never short-circuit, so permissions were rebuilt and re-applied on every call. This PR fixes the root cause with a one-line change.

Fixes #1317

Root cause

The function caches the previous result in permissionsRef and guards its work by comparing the incoming permissions against the previously stored raw permissions:

JSON.stringify(permissions) !== JSON.stringify(permissionsRef.current.raw)

However, the ref was only ever assigned { map: permissionsMap }, leaving .raw permanently undefined. The guard therefore reduced to someJSONString !== undefined, which is always true — so the
change-detection never took effect.

Impact

Because the guard never short-circuited, every invocation of fetchAndSetPermissions would:

• Rebuild the permissions Map via createPermissionsMap, and
• Run applyPermissions, firing all six Zustand permission setters (viewUserInfo, deleteMessage, deleteOwnMessage, forceDeleteMessage, userPin, editMessage).

This resulted in redundant store writes and unnecessary re-renders even when the permissions returned by the server had not changed.

Fix

Persist the raw permissions alongside the map so the comparison has a real previous value and can correctly skip the work when nothing changed:

permissionsRef.current = {
  raw: permissions,
  map: permissionsMap,
};

• Files changed: 1 — packages/react/src/hooks/useFetchChatData.js
• Lines changed: +1
• No public API, signature, or behavioral change when permissions do change; unchanged permissions simply no longer trigger redundant work.

Acceptance Criteria fulfillment

• fetchAndSetPermissions no longer rebuilds the permissions map on every call
• applyPermissions and the six permission setters only run when permissions actually change
• Permission updates continue to apply correctly when permissions change
• Change is minimal and scoped to the affected hook

How to test

1. Open a channel and confirm permission-gated actions still work: edit message, delete message, delete own message, force delete, pin message, and view full user info.
2. Trigger fetchAndSetPermissions repeatedly with unchanged permissions and confirm the six setters no longer fire on each call (no redundant updates).
3. Change a relevant permission on the server, fetch again, and confirm the new permissions are applied correctly.

Video/Screenshots

N/A — no visual change. This PR removes redundant state updates; user-facing
behavior is identical when permissions actually change.

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

Restores the intended permission change-detection behavior in useFetchChatData by persisting the previously fetched raw permissions alongside the derived permissions map, so the hook can correctly skip rebuilding/reapplying permissions when nothing has changed.

Changes:

• Store raw: permissions into permissionsRef.current so the JSON comparison guard can short-circuit correctly.
• Prevent redundant createPermissionsMap() work and applyPermissions() store writes when permissions are unchanged.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.