[$250] [INP] Improve `UserListItem-Checkbox` interaction

[rlinoz]

Improve the INP (Interaction to Next Paint) of the interaction labeled UserListItem-Checkbox in Sentry — the selection checkbox on user/list rows.

• Label: CONST.SENTRY_LABEL.USER_LIST_ITEM.CHECKBOX — assigned in src/components/SelectionList/components/ListSelectionButton.tsx

Follow the INP Improvement Workflow.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070553872495265830
• Upwork Job ID: 2070553872495265830
• Last Price Increase: 2026-07-03

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (External)

[kitvasyl]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Selecting a user/list row checkbox is showing poor INP for the UserListItem-Checkbox interaction because the checkbox press waits on synchronous selection-list work before the next paint.

What is the root cause of that problem?

The expensive gate is in src/components/SelectionList/BaseSelectionList.tsx. ListSelectionButton labels the interaction, but the blocking work happens after its onPress={() => onSelectRow(item)} path reaches BaseSelectionList.selectRow() and updates selection state.

On the following render, BaseSelectionList recalculates dataDetails by reducing over every data item. For each item it calls isItemSelected, and isItemSelected currently checks membership with selectedItems.includes(item.keyForList). That makes each checkbox toggle do repeated linear scans of selectedItems across the whole list, so large user/member lists pay O(data.length * selectedItems.length) synchronous JS work before the checkbox state can paint.

What changes do you think we should make in order to solve the problem?

Convert selectedItems to a memoized Set inside BaseSelectionList and use constant-time membership in isItemSelected:

const selectedItemsSet = useMemo(() => new Set(selectedItems), [selectedItems]);

const isItemSelected = useCallback(
    (item: TItem) => item.isSelected ?? ((isSelected?.(item) ?? selectedItemsSet.has(item.keyForList)) && canSelectMultiple),
    [isSelected, selectedItemsSet, canSelectMultiple],
);

This keeps the existing selection precedence (item.isSelected, then custom isSelected, then selectedItems) and only changes the lookup structure used by the hot checkbox render path. It also improves both dataDetails and visible-row selection checks without touching page-specific toggle handlers.

Manual verification: open a multi-select user/member list with many rows, select and deselect several checkboxes, confirm the visual selected state, select-all state, disabled checkbox handling, and keyboard selection still match current behavior while the Sentry INP span for UserListItem-Checkbox improves.

What alternative solutions did you explore? (Optional)

We could defer onSelectRow from ListSelectionButton with requestAnimationFrame, but that only masks the delay and changes event timing for every checkbox/radio consumer. Optimizing the membership check in BaseSelectionList removes the synchronous work from the shared hot path with a smaller behavior surface.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022070553872495265830

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-26 17:15:17 UTC.

Proposal

What is the root cause of that problem?

The UserListItem-Checkbox interaction is the checkbox tap. Its onPress calls onSelectRow(item) (ListSelectionButton.tsx#L56) → BaseSelectionList.selectRow → the parent flips the row's selection. That selection state lives on the list screen, so BaseSelectionList re-renders and renderItem runs again for every visible row.

The reason this is expensive is what re-runs per row, not just how many rows re-run. Each visible row mounts UserListItemContent, whose dominant cost is ReportActionAvatars:

UserListItemContent.tsx#L90-L105

ReportActionAvatars is exported un-memoized (ReportActionAvatars/index.tsx#L233) and its hook subscribes to the entire PERSONAL_DETAILS_LIST plus several REPORT/REPORT_ACTIONS collections (useReportActionAvatars.ts#L71). None of the avatar inputs (item.reportID, item.accountID, item.policyID, item.icons, item.text) change when a checkbox toggles — yet the whole avatar subtree re-renders on every toggle, for every visible row. There is also a per-row useOnyx(REPORT...) in the same component (UserListItemContent.tsx#L64-L66).

Why memoization can't bail out today, even with React Compiler. Two layers each hand the row a brand-new item object on every toggle:

1. The shared renderItem allocates a fresh item literal per row per render — BaseSelectionList.tsx#L289-L293 (item={{shouldAnimateInHighlight, isSelected, ...item}}).
2. More importantly, the callers themselves rebuild the entire options array on every toggle, baking isSelected into a fresh object per row. The most common multi-select user lists do exactly this:
   • ShareBankAccount.tsx#L114-L116 — admins.map(admin => ({...admin, isSelected: selectedOptions.some(...)})), a new object per row plus an O(n²) .some() scan on each render.
   • AddDelegatePage.tsx#L91-L100 — sections.map(... data.map(option => ({...option, ...}))), again a new object per row.

So the item reference reaching the row is already referentially new at the source on every toggle. This is the key point: stabilizing the item reference inside BaseSelectionList (or wrapping the row in a plain React.memo) cannot bail these rows out, because their item prop is a different object every time regardless — the new reference is created upstream in the page, before the list ever sees it.

So: checkbox toggle → parent rebuilds all option objects → all visible rows get a referentially-new item → each row re-renders its full UserListItemContent → un-memoized ReportActionAvatars recomputes for every row → paint is blocked on N avatar subtrees → high INP that scales with rows on screen.

What changes do you think we should make in order to solve the problem?

Isolate the selection-independent, expensive part of the row so a toggle stops re-rendering it — and do it in a way that survives the upstream "rebuild all options" pattern (i.e. keyed on the primitive fields, not on item identity). This is the "split the re-rendered component into smaller parts" technique from step 6.1 of the INP workflow.

Concretely, in UserListItemContent (L83-L136) extract the avatar block (L90-L105) into its own component wrapped in React.memo whose props are the primitive avatar inputs (reportID, accountID, policyID, and the border/focus flags), not the whole item:

const RowAvatars = React.memo(function RowAvatars({reportID, accountID, policyID, isFocused, isHovered, ...}) { /* ReportActionAvatars */ });

Because the memo compares reportID/accountID/policyID/isFocused — none of which change on a selection toggle — the avatar subtree (and its PERSONAL_DETAILS_LIST/REPORT work) is skipped even when the parent handed the row a brand-new item object. Only the cheap checkbox indicator re-renders on toggle. This holds for both ShareBankAccount-style (rebuilt options) and stable-data lists.

ReportActionAvatars being exported un-memoized (index.tsx#L233) is the same root issue one layer down; the extracted RowAvatars boundary fixes it at the list-row level without touching every other ReportActionAvatars caller. Since UserListItemContent is the shared inner content for both UserListItem and BareUserListItem, the win applies to every user/member multi-select list at once. Exact prop shape and split boundary can be refined in the PR phase, validated with a production React Profiler trace (10 before / 10 after through the trace-analyzer) per steps 4–9 of the workflow.

What alternative solutions did you explore? (Optional)

Stabilize the per-row item reference in BaseSelectionList and wrap the row in React.memo. This helps lists that pass a referentially-stable data array, but it does not help the dominant real callers — ShareBankAccount.tsx#L114-L116 and AddDelegatePage.tsx#L91-L100 rebuild every option object on each toggle, so the row's item prop is a new reference no matter what BaseSelectionList does, and a plain shallow React.memo never bails out. Memoizing the selection-independent subtree on its primitive inputs is robust to that upstream rebuild, which is why it is the better primary fix. (A separate, complementary cleanup is converting those callers' O(n²) .some() membership checks to a Set, but that trims the page's own re-render, not the avatar work on the INP critical path.)

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[dilshodmackbook-sketch]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The UserListItem-Checkbox interaction (the selection checkbox on user/list rows, labeled via CONST.SENTRY_LABEL.USER_LIST_ITEM.CHECKBOX in ListSelectionButton) reports a poor INP: when a checkbox is tapped, the next paint is delayed by synchronous selection-list work that runs on the same render before the toggled checkmark can be shown.

What is the root cause of that problem?

Tapping the checkbox calls onPress={() => onSelectRow(item)} (ListSelectionButton.tsx#L57), which updates selection state and re-renders BaseSelectionList.

On that re-render, before React can paint, BaseSelectionList synchronously rebuilds dataDetails by reducing over every item in data — not just the visible rows — to recompute the select-all tri-state (allSelected/someSelected), selectedOptions, and the disabled-index arrays: BaseSelectionList.tsx#L123-L160. Because isItemSelected (a dependency of this memo) changes on every selection update (BaseSelectionList.tsx#L114-L117), the full reduce re-runs on every toggle.

The key observation is that none of that aggregate work is needed for the paint that closes the interaction. The toggled checkbox's checkmark is driven by the row's own isSelected (renderItem computes selected = isItemSelected(item) per row at BaseSelectionList.tsx#L277-L323), independent of dataDetails. dataDetails only feeds the select-all header and keyboard-focus index arrays. So a whole-list O(data.length) reduce sits on the critical paint path purely to refresh UI that does not have to update in the same frame as the checkmark.

What changes do you think we should make in order to solve the problem?

Take the whole-list aggregate reduce off the checkbox's critical paint path with useDeferredValue, so the toggled checkmark paints immediately and the select-all summary catches up on the following (non-blocking) commit.

In BaseSelectionList, defer the input the aggregate memo reduces over, and key the memo off the deferred value:

const deferredData = useDeferredValue(data);

const dataDetails = useMemo<DataDetailsType<TItem>>(() => {
    const {disabledIndexes, disabledArrowKeyIndexes, selectedOptions, disabledSelectedIndexes} = deferredData.reduce(
        // ...unchanged reduce body...
    );
    // ...unchanged aggregate calculations...
}, [canSelectMultiple, deferredData, isDisabled, isItemSelected]);

On the urgent render right after a toggle, deferredData still equals the previous array, so the memo returns its cached result and the expensive reduce does not run before paint. FlashList keeps rendering the fresh data, and renderItem keeps reading the fresh per-row isItemSelected, so the tapped checkbox repaints in the same frame. React then schedules a background render where deferredData updates and the reduce runs off the interaction's critical path — the select-all tri-state and keyboard disabled-index arrays land one commit later, which is imperceptible.

This removes synchronous work from the shared hot path for every list that uses the checkbox, regardless of how each consumer stores its selection (it does not depend on whether the page toggles selectedItems or rebuilds data).

Manual verification: open a multi-select user/member list with many rows, toggle several checkboxes, and confirm the checkmark, select-all tri-state, disabled handling, and keyboard selection still match current behavior while the Sentry INP span for UserListItem-Checkbox improves.

What alternative solutions did you explore? (Optional)

• Cut the per-toggle re-render fan-out instead: renderItem is an inline function that builds a fresh {...item} object and inline closures for every row on each render, so every visible ListItem reconciles even when only one row's selection changed. Extracting the row body into a dedicated component the React Compiler can memoize would let unchanged rows bail out. It is a valid complementary improvement but touches more surface than the deferral above, so I'd lead with the deferral.
• I did not consider deferring the press handler with InteractionManager.runAfterInteractions: the INP Improvement Workflow explicitly disallows new InteractionManager usages (it is being removed from the codebase), and it would change event timing for every checkbox/radio consumer rather than removing the synchronous work.

[github-actions]

⚠️ @dilshodmackbook-sketch Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[lorretheboy]

Proposal

What is the root cause of that problem?

The UserListItem-Checkbox interaction is the checkbox tap. Its handler ultimately calls selectRow → onSelectRow(item), which toggles that one row's isSelected in the parent. That state lives on the list screen, so the whole BaseSelectionList re-renders and the list re-runs renderItem for every visible row, not just the tapped one.

The expensive part is that those re-runs aren't cheap. For each visible row, renderItem allocates a brand-new item object literal every render here:

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 288 to 292 in 92333d2

	item={{
	shouldAnimateInHighlight: isItemHighlighted,
	isSelected: selected,
	...item,
	}}

and ListItemRenderer is exported with no memoization:

App/src/components/SelectionList/ListItem/ListItemRenderer.tsx

Line 119 in 92333d2

export default ListItemRenderer;

So even rows whose isSelected did not change receive a referentially-new item prop and re-render their entire subtree (the ReportActionAvatars, text, and the checkbox itself in UserListItemContent). One checkbox toggle therefore costs a full re-render of all visible rows → high INP that scales with the number of rows on screen.

What changes do you think we should make in order to solve the problem?

Fix it at the shared convergence point both lists go through (ListItemRenderer):

1. Wrap ListItemRenderer in React.memo so an unchanged row can bail out of re-render:

App/src/components/SelectionList/ListItem/ListItemRenderer.tsx

Line 24 in 92333d2

function ListItemRenderer<TItem extends ListItem>({

2. Stop allocating a fresh item object per row per render in renderItem, so memo actually holds for unchanged rows. Instead of merging into a new literal, pass the row's own stable item reference through and forward isSelected/shouldAnimateInHighlight as discrete props:

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 288 to 292 in 92333d2

	item={{
	shouldAnimateInHighlight: isItemHighlighted,
	isSelected: selected,
	...item,
	}}

selectRow and setFocusedIndex are already useCallback-stable, so after these two changes a checkbox toggle only re-renders the row that actually changed.

The same renderer is used by the sections list, so it benefits from the identical fix:

App/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

Line 265 in 92333d2

<ListItemRenderer

What alternative solutions did you explore? (Optional)

Defer the non-visual part of the toggle (e.g. wrap the selection state update in startTransition) so the checkbox paints immediately while the list reconciles a frame later. This helps perceived responsiveness but doesn't remove the redundant per-row work, so memoizing the row is the better primary fix.