[Performance] Opening invite dialog causes full table re-render (Members Table Fully Refactored)

[RajuGangitla]

Problem:
Opening the "Add Member" dialog triggers a full re-render of the entire MembersTable component tree. This was profiled with React Scan and confirmed at scale with 50 members/invitations.

Root Cause:
inviteDialogOpen state lives inside MembersTable. When the "+ Add" button is clicked, setInviteDialogOpen(true) updates state on the parent component, causing the entire table — all rows, cells, badges, and dropdowns — to re-render unnecessarily.
Same issue exists for changePasswordDialogOpen state.

Proposed Fix:
Basically Members Table Refactoring and Extract the invite button + dialog into an isolated InviteButton component so the open/close state is scoped locally and doesn't bubble up to MembersTable.

Proof (tested with 50 members) :

members.webm

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[JiwaniZakir]

The re-render cascade is a classic React state colocation problem — inviteDialogOpen and changePasswordDialogOpen both living in MembersTable means any state toggle invalidates the entire component subtree, including all rows, cells, and dropdowns, even though none of them depend on dialog state. The fix of extracting InviteButton (and similarly a ChangePasswordButton) into self-contained components with locally scoped state is the right approach, since React only re-renders from the component where setState is called downward. It's also worth ensuring that any callback props passed into table rows (e.g., onAction handlers) are stabilized with useCallback and row data with useMemo, otherwise the extracted components can still trigger row re-renders if referential equality breaks on each parent render.

[RajuGangitla]

@JiwaniZakir yes seperate the state in such a way that it reduce unnecessary rerenders

Already raised a pr

[JiwaniZakir]

The approach of extracting InviteButton into its own component with locally scoped state is the right fix — colocating state with the component that owns it prevents unnecessary rerenders up the tree. While you're at it, make sure any callbacks passed to table rows (e.g., for the change password dialog) are wrapped in useCallback to avoid breaking memoization on React.memo-wrapped row components. The test report showing 3 failures is worth investigating before merging to confirm none are related to the dialog state changes.

[RajuGangitla]

@dimaMachina, could you please check this issue as well? I’ve opened a PR for it—would appreciate your feedback on whether it works.

[JiwaniZakir]

The root cause analysis is correct — colocating inviteDialogOpen inside InviteButton is the right fix. You'll also want to make sure the table rows are memoized with React.memo and that any callbacks passed as props (like onRoleChange, onRemove) are wrapped in useCallback, otherwise moving the dialog state alone won't fully eliminate the re-renders. The same pattern should apply to changePasswordDialogOpen — extract it into a ChangePasswordButton or similar wrapper scoped to the individual row.

[RajuGangitla]

changePasswordDialogOpen and ChangePasswordButton are both already extracted to the member row level, it won't trigger full table re-renders. even though we extract this to a separate component there is no proper gains in performance (because only one row is going to rerender which is totally fine). the main goal of this PR is not to rerender the full table because that is expensive.

FYI, check the below video of opening an changePasswordDialog, ChangePasswordButton, other dialogs which are already green (i mean good processing time) extracting this to seperate component will be overoptimistaion and hard code readbillity. So, Thank you for your suggestion @JiwaniZakir

issue.webm

[JiwaniZakir]

The fix is straightforward — colocating the inviteDialogOpen and changePasswordDialogOpen states inside isolated components (InviteButton, ChangePasswordButton) prevents the state updates from propagating up to MembersTable and triggering unnecessary re-renders across the entire tree. You can also wrap individual row components with React.memo as a secondary guard. Given the PR was closed due to inactivity, rebasing onto latest main should be low-friction since this is a self-contained refactor with no likely conflicts.