[Due for payment 2026-08-25] [$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-17

Issue Owner

Current Issue Owner: @aimane-chnaif

[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]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-13 10:57:33 UTC.

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 work that runs before the toggled checkmark can be shown.

What is the root cause of that problem?

I profiled this on a production web build (2,000 contacts, /new/chat group multi-select, 4x CPU throttle, commit-level attribution via the profiling reconciler) rather than reasoning from the code, because the code path suggests several plausible culprits and they don't all survive measurement:

• The whole-list aggregate reduce in flat BaseSelectionList (dataDetails) — the root cause my original proposal and several others centered on — is not the cost. I applied a deferral of that reduce and measured it: INP was unchanged (avg 117 ms -> 119 ms). /new/chat renders through SelectionListWithSections, which doesn't run that reduce at all, and even at 2,000 rows the reduce itself is sub-millisecond.
• The measured blocker is a single ~51 ms React commit (plus its style/layout/paint) that lands inside the tap's paint window. Tapping the checkbox calls onPress={() => onSelectRow(item)} (ListSelectionButton.tsx#L55-L61) -> toggleOption -> setSelectedOptions (NewChatPage/index.tsx#L319-L349), and that one urgent state update re-runs the page's entire selection-derived pipeline synchronously:
  1. getValidOptions + filterAndOrderOptions rebuild every option object because selectedOptions is one of their inputs (NewChatPage/index.tsx#L125-L156);
  2. the sections get new references, so useFlattenedSections re-clones every loaded row ({...item} per item — all 2,000 once the user has scrolled) (useFlattenedSections.ts#L70-L78);
  3. every visible row re-renders because all item references changed, and the full list re-lays-out and repaints.

None of that work is needed for the paint that closes the interaction: the only pixel that must change on the tap frame is the tapped row's checkmark. The select-all summary, the other rows, and the recomputed option ordering can all land a frame later without any visible difference.

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

Split the tap into an urgent, tiny update (the checkmark) and a transition (everything else). This is the same urgent-feedback + startTransition split that was applied for the PrevNextButtons-NextButton INP issue (#94721, PR #95737).

1. ListSelectionButton — paint the checkmark optimistically on press. Local state flips the checkbox immediately; it reconciles with item.isSelected when the deferred update lands (state-adjustment-during-render, the pattern documented in the React docs). Verified it compiles under React Compiler.

// Paint the checkmark immediately on press, even when the parent defers the (expensive) selection-state
// update in a transition. The optimistic value is dropped as soon as the item prop catches up.
const isCheckedProp = item.isSelected ?? false;
const [prevCheckedProp, setPrevCheckedProp] = useState(isCheckedProp);
const [optimisticChecked, setOptimisticChecked] = useState<boolean | null>(null);
if (prevCheckedProp !== isCheckedProp) {
    setPrevCheckedProp(isCheckedProp);
    setOptimisticChecked(null);
}
const isChecked = optimisticChecked ?? isCheckedProp;

return (
    <SelectionButton
        // ...unchanged props...
        isChecked={isChecked}
        onPress={() => {
            setOptimisticChecked(!isChecked);
            onSelectRow(item);
        }}

2. NewChatPage.toggleOption — run the heavy selection update as a transition, and read membership from the selection state (not the possibly-stale item) so rapid toggles stay correct while a previous transition is still catching up.

const toggleOption = (option: ListItem & Partial<OptionData>) => {
    const isOptionInList = selectedOptions.some((selectedOption) => selectedOption.login === option.login);

    let newSelectedOptions: SelectedOption[];

    if (isOptionInList) {
        newSelectedOptions = reject(selectedOptions, (selectedOption) => selectedOption.login === option.login);
    } else {
        newSelectedOptions = [...selectedOptions, {...option, isSelected: true, reportID: option.reportID, keyForList: `${option.keyForList ?? option.reportID}`}];
    }

    selectionListRef.current?.clearInputAfterSelect();
    if (!canUseTouchScreen()) {
        selectionListRef.current?.focusTextInput();
    }

    // The selection update fans out into the whole options pipeline (getValidOptions -> filterAndOrderOptions ->
    // sections -> useFlattenedSections -> every visible row re-render). Run it as a transition so the tapped
    // checkbox (which shows optimistic feedback) can paint first and the heavy re-render doesn't block the frame.
    startTransition(() => {
        setSelectedOptions(newSelectedOptions);

        if (!personalData?.login || !personalData?.accountID) {
            return;
        }
        const participants: SelectedParticipant[] = [
            ...newSelectedOptions.map((selectedOption) => ({
                login: selectedOption.login,
                accountID: selectedOption.accountID ?? CONST.DEFAULT_NUMBER_ID,
            })),
            {
                login: personalData.login,
                accountID: personalData.accountID,
            },
        ];
        setGroupDraft({participants});
    });
};

Working branch with the verified change: main...dilshodmackbook-sketch:App:poc-94722-checkbox-inp

Measured results (production staging build, /new/chat group multi-select with 2,000 contacts, 4x CPU throttle, 10 trace samples per variant, captured with the INP-approximating window from the INP Improvement Workflow): average total duration inside the tap's paint window drops from 57.57 ms to 16.75 ms (-70.9%) — see the trace comparator screenshots. Before the change, the ~51 ms full-pipeline commit sits inside the interaction window; after it, the heavy commit lands one frame later (time-sliced, non-blocking). The checkmark still changes on the tap frame — this is not a case of deferring the visible feedback.

The change is behavior-preserving: selection results, group draft contents, search clearing, and focus handling are unchanged; only the scheduling of the re-render moves.

What alternative solutions did you explore? (Optional)

• Deferring the dataDetails aggregate reduce in flat BaseSelectionList (my original proposal, and the shared root cause of several others): implemented and measured — no INP change on this label's dominant path (avg 117 ms -> 119 ms), because /new/chat renders via SelectionListWithSections and the reduce is sub-millisecond even at 2,000 rows. It could still be a micro-improvement for flat-list consumers, but it does not address this issue's metric.
• Reducing per-row render cost (memoizing the row renderer with a comparator, or extracting the avatar subtree so it can bail out — directions other proposals explore): complementary, but on this page every item object is recreated on each toggle by the options pipeline, so the pipeline itself (options rebuild + section flattening) stays on the paint-critical path; moving the whole update into a transition takes all of it off at once, and the two approaches can be combined later if row cost still matters.
• Deferring the press handler with InteractionManager.runAfterInteractions: disallowed by the INP Improvement Workflow (it is being removed from the codebase).

[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).

[dilshodmackbook-sketch]

Proposal updated