[Performance] Isolate dialog state to scoped row components to eliminate table re-renders#2807
[Performance] Isolate dialog state to scoped row components to eliminate table re-renders#2807RajuGangitla wants to merge 8 commits intoinkeep:mainfrom
Conversation
|
|
@RajuDev0 is attempting to deploy a commit to the Inkeep Team on Vercel. A member of the Team first needs to authorize it. |
Ito Test Report ❌16 test cases ran. 1 failed, 15 passed. Overall, the unified members-page QA run passed 15 of 16 test cases, confirming stable behavior for core admin workflows and edge cases including page/table rendering, invitation creation and pending-row actions, dialog reset and rapid-click isolation, row-scoped role/delete/revoke flows, idempotent destructive actions, empty-state rendering, clipboard-denial resilience, invitation-link tamper rejection and URL-encoding safety, and non-admin access restrictions. The only failure was a medium-severity concurrent multi-tab stale-confirmation bug where revoking an invite in one tab and then confirming a stale revoke modal in another can incorrectly show a success toast instead of an already-revoked conflict state, indicating missing conflict handling in the revoke/confirmation logic. ❌ Failed (1)
🟠 Stale revoke confirmation reports success after invitation already changed
Relevant code:
const handleRevokeInvitation = async (inv: Invitation) => {
setRevokingInvitation(inv.id);
try {
const { error } = await authClient.organization.cancelInvitation({
invitationId: inv.id,
});
if (error) {
toast.error('Failed to revoke invitation', {
description: error.message || 'An error occurred while revoking the invitation.',
});
return;
}
toast.success('Invitation revoked', {
description: `Invitation to ${inv.email} has been revoked.`,
});
onInvitationRevoked?.();
const handleConfirm = async () => {
if (!data) return;
setIsLoading(true);
try {
await options.onConfirm(data);
closeModal();
} catch (error) {
setIsLoading(false);
throw error;
}
};✅ Passed (15)
Commit: Tell us how we did: Give Ito Feedback |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Ito Test Report ✅19 test cases ran. 19 passed. The unified members-page QA run passed 19/19 test cases with zero failures, confirming baseline admin access and rendering on /default/members (including a successful /api/auth/dev-session 200 {"ok":true} checkpoint) and overall stability across member/invitation management flows. Most importantly, authorization and safety controls held under adversarial behavior: non-admin users remained strictly read-only with no admin controls exposed via deep links/history churn, row-scoped modals and loading prevented cross-row mis-targeting during rapid or concurrent actions, invite workflows correctly handled reset/validation/mixed outcomes/double-submit and malicious input without side effects, revoke/copy-link behaviors were correct (single effective revoke, same-origin URL-encoded links), and edge usability conditions (empty-tenant state, refresh/back-forward interruptions, and mobile viewport interactions) all behaved as intended. ✅ Passed (19)
Commit: Tell us how we did: Give Ito Feedback |
Ito Test Report ❌20 test cases ran. 1 failed, 19 passed. The unified members-management run completed 20 test cases with 19 passing and 1 failing, confirming expected behavior across page rendering and self-guardrails, invitation create/revoke/link format flows, role and project-access updates, password actions, non-admin permission boundaries, mobile/refresh-navigation resilience, and adversarial safety/race scenarios (including malformed input rejection and tampered invitation-link handling). The only significant finding was a medium-severity pre-existing defect in Copy invite link where clipboard write failures are not awaited/caught, causing a false “Invite link copied” success toast even when copying is denied, which can mislead users and disrupt invitation sharing. ❌ Failed (1)
🟠 Clipboard-denied invite copy still shows success toast
Relevant code:
const handleCopyInviteLink = () => {
const link = `${window.location.origin}/accept-invitation/${invitation.id}?email=${encodeURIComponent(invitation.email)}`;
navigator.clipboard.writeText(link);
toast.success('Invite link copied');
};
<InvitationActionsMenu
invitation={invitation}
isOrgAdmin={isOrgAdmin}
onRevokeInvitation={(inv) => revokeModal.openModal(inv)}
/>✅ Passed (19)
Commit: Tell us how we did: Give Ito Feedback |
Ito Test Report ❌19 test cases ran. 1 failed, 18 passed. Overall, 19 end-to-end checks on /default/members and related invitation flows ran with 18 passes and 1 failure, confirming stable behavior across route rendering/sorting, admin and non-admin permission boundaries, invite validation and mixed outcomes, revoke/delete actions, role changes, project access management, navigation/refresh idempotency, mobile viewport usability, and invitation-link tampering safety. The single confirmed product issue is a medium-severity bug in Add Team Members results where clicking Copy link shows a success toast even when clipboard-write permission is denied, causing false-positive feedback and potential invite-sharing delays. ❌ Failed (1)
🟠 Clipboard denial is misreported as successful invite link copy
Relevant code:
{result.status === 'success' && result.link && (
<Button
type="button"
size="sm"
variant="ghost"
className="h-7 px-2 text-xs gap-1 shrink-0"
onClick={() => {
if (result.link) {
navigator.clipboard.writeText(result.link);
toast.success('Invite link copied');
}
}}
>
const result = await createPasswordResetLink({
tenantId: organizationId,
email: member.user.email,
});
await navigator.clipboard.writeText(result.url);
toast.success('Reset link copied to clipboard', {
description: 'Share the reset password link with the user.',
duration: 6000,
});
} catch (err) {
toast.error('Failed to create reset link', {
description: err instanceof Error ? err.message : 'An unexpected error occurred.',
});✅ Passed (18)
Commit: Tell us how we did: Give Ito Feedback |
Ito Test Report ❌19 test cases ran. 3 failed, 16 passed. Overall, 19 test cases were run with 16 passing and 3 failing, and the passing coverage showed stable behavior across core members/invitations flows including admin route rendering, row-scoped modal/state isolation, invite create/revoke/copy/accept paths, validation and mixed-result handling, rapid revoke stability, tamper rejection on accept links, graceful clipboard-error handling, role-demotion and concurrent row actions, self-row restrictions, navigation interruption recovery, callback-driven refresh, and mobile portrait/landscape usability. The three confirmed defects were: a high-severity authorization gap where an admin can delete an owner via direct remove-member API despite UI protections, a medium-severity Add Members race allowing rapid repeated submits to trigger duplicate invite attempts, and a medium-severity empty-state logic issue where tenants with only the current user do not show the expected “No members yet” fallback. ❌ Failed (3)
🟠 Rapid repeated Add Members submission can create duplicate invites
Relevant code:
const handleSubmit = async (e: React.FormEvent) => {
e.preventDefault();
if (!emails.trim()) {
setError('At least one email is required');
return;
}
if (!organizationId) {
setError('No organization selected');
return;
}
if (!isOrgAdmin) {
setError('You are not authorized to invite members');
return;
}
setIsSubmitting(true);
setError(null);
setInvitationResults([]);
<Button type="submit" disabled={isSubmitting || !emails.trim()}>
{isSubmitting ? 'Adding...' : 'Add Members'}
</Button>🟠 Empty-state rendering when no members and no invitations
Relevant code:
{members.length === 0 && pendingInvitations.length === 0 ? (
<TableRow noHover>
<TableCell colSpan={4} className="text-center text-muted-foreground">
No members yet.
</TableCell>
</TableRow>
) : (
<>
<MembersTable
members={organization?.members || []}
pendingInvitations={pendingInvitations}
currentMember={currentMember}
organizationId={tenantId}
onMemberUpdated={fetchData}
isOrgAdmin={isOrgAdmin}
|
| Category | Summary | Screenshot |
|---|---|---|
| Adversarial | Rapid repeated revoke confirmation produced a single effective revoke outcome and left the members UI stable. |  |
| Adversarial | Malformed invite entries were rejected, and a corrected valid email invite succeeded. |  |
| Adversarial | A tampered email query was blocked while the valid invitation link loaded the join flow. |
 |
| Adversarial | Clipboard write failure handling is non-blocking and does not create a crash or freeze path. |  |
| Edge | Self-row exposed only Change password, with no self-delete or self role edit path. |  |
| Edge | Invalid invite tokens were rejected, then corrected mixed input produced per-email success/failure results and clean dialog completion. |  |
| Edge | Refresh/back-forward interruptions recovered without ghost overlays or blocked controls. |  |
| Logic | Row-scoped modal/action state stayed isolated across invitation and admin rows. |  |
| Logic | Concurrent row actions stayed row-scoped without table-wide locking. |  |
| Logic | On /default/members, invitation-side mutations refreshed row state correctly: newly invited pending row appeared immediately after Done, and the same row disappeared immediately after revoke confirmation, with no manual page reload required. |  |
| Mobile | In portrait (390x844) and landscape (844x390), header/badge/Add remained reachable; member and invitation row menus opened; invite copy action and dialogs worked without stuck overlays. |  |
| Happy-path | Members route loaded for admin with Add control and table columns visible. |  |
| Happy-path | Admin invited a unique member email via Add dialog, closed with Done, and saw a pending invitation row without stale dialog state. |  |
| Happy-path | Role demotion opened Assign to Projects and Skip returned cleanly to the members table. |  |
| Happy-path | Pending invitation was revoked from the row action flow and removed successfully with confirmation feedback. |  |
| Happy-path | Copied invitation link opened the accept-invitation route with valid invitation UI on localhost. |  |
Commit: acce7f0
Tell us how we did: Give Ito Feedback
Ito Test Report ✅20 test cases ran. 20 passed. The unified members/invitations verification run passed completely (20/20 test cases), showing stable rendering and control behavior on /default/members across baseline, edge, advanced, mobile, navigation, and empty-state scenarios with no plausible production defects identified in reviewed code paths. Key findings were that admin actions remained correctly row-scoped and resilient under rapid interaction (single invite dialog, accurate role/reset/delete targeting, idempotent destructive confirms), invitation handling was secure and correct (pending-list refresh, malformed email rejection, safe URL-encoded link copy, tampered accept-link rejection, revoke recovery after refresh), and authorization/session safety held (non-admin read-only with bypass attempts blocked, and mid-confirmation session invalidation failing safely without unintended data mutation). ✅ Passed (20)
Commit: Tell us how we did: Give Ito Feedback |
Ito Test Report ✅19 test cases ran. 19 passed. The unified run passed all 19 of 19 test cases with zero failures, confirming stable Members page behavior across baseline rendering, alphabetical sorting, invite dialog lifecycle, role-change workflows, delete/revoke confirmations, invite-link handling, and navigation/mobile recovery. Most importantly, state and dialogs stayed correctly row-scoped under rapid/concurrent interactions (including double-submit/double-confirm races), malformed invite input was safely rejected without script execution or partial submission, revoked invite links were invalidated as expected, and non-admin privilege-escalation attempts were blocked by both UI and backend authorization with no unauthorized data changes. ✅ Passed (19)
Commit: Tell us how we did: Give Ito Feedback |
Ito Test Report ✅14 test cases ran. 14 passed. The unified members-management test run passed completely (14/14), confirming core admin workflows on /default/members including page load, scoped menus, invite creation, role updates, demotion-triggered assign-project handling, invitation revocation, and member deletion with correct table refresh behavior. The most important findings were strong safety and isolation guarantees: non-admin users could not access privileged controls or cross-tenant routes, malformed invite payloads were rejected, rapid keyboard/click abuse did not trigger hidden or duplicate destructive actions, dialogs remained correctly row-scoped across rapid switching, refresh/back-forward and mobile (390x844) interactions stayed stable, and no UI lockups were observed. ✅ Passed (14)
Commit: Tell us how we did: Give Ito Feedback |
2 participants
Fixes: #2806
Summary:
Refactored MembersTable to eliminate cascading re-renders caused by dialog state living at the table level. Previously, opening any dialog (invite, change password, delete confirm, role change, revoke) triggered a full re-render of all 50+ rows.
Benchmark results (50 members/invitations) (After Optimisation) :
Changes:
Extracted InviteButton — owns inviteDialogOpen state + InviteMemberDialog
Extracted MemberRow — owns all per-member dialog state: ChangePasswordDialog, ProjectAccessDialog, MemberConfirmationModals (delete + role change)
Extracted InvitationRow — owns revokeModal + MemberConfirmationModals
MembersTable now has zero useState calls — pure layout/sorting component
please check this video:
opti-members.webm