ConfirmationPage - Composition over Configuration (full migration) #101224

Problem

ConfirmationPage is a configuration-style wrapper: 24 flat props on ConfirmationPage.tsx:25-77. Ten of them exist only to configure its two buttons, and seven more are *Style escape hatches that exist because callers can't reach the regions they need to restyle:

// buttons
buttonText, onButtonPress, shouldShowButton, isButtonDisabled, isButtonLoading,
secondaryButtonText, onSecondaryButtonPress, shouldShowSecondaryButton,
isSecondaryButtonDisabled, isSecondaryButtonLoading
// style patches
headingStyle, illustrationStyle, descriptionStyle, ctaStyle, footerStyle,
containerStyle, innerContainerStyle

Every new capability means another should* / is* / on*Press / *Text / *Style prop. The shape doesn't scale to a third button, to button content the wrapper never anticipated (an icon, a DotIndicator, a badge), or to any per-screen layout ConfirmationPage didn't predict. It also already carries two duplicate string-or-node pairs — description / descriptionComponent and cta / ctaComponent — which is the configuration API admitting it needs slots.

feat: add request access button to the domain access restricted screen added two of those props (isSecondaryButtonDisabled, isSecondaryButtonLoading) and ZhenjaHorbach flagged the prop count in review.

This is the same "composition over configuration" problem as Button - Composition over Configuration, one layer up: decomposing Button itself doesn't help callers if the wrapper in between re-flattens the API.

Scope note: this issue originally covered only the 10 button props. Per the follow-up discussion it now covers the full ConfirmationPage migration to a compound component.

Proposal

Migrate ConfirmationPage to a compound component. Each region it renders becomes a slot the caller composes, matching the Button.Icon / Button.Text / Button.KeyboardShortcut shape already shipped in Button/index.tsx:29-33.

<ConfirmationPage>
    <ConfirmationPage.Illustration src={LottieAnimations.Fireworks} />
    <ConfirmationPage.Heading>{translate('domain.accessRestricted.title')}</ConfirmationPage.Heading>
    <ConfirmationPage.Description>{translate('domain.accessRestricted.description')}</ConfirmationPage.Description>
    <ConfirmationPage.Footer>
        <ConfirmationPage.Button
            isDisabled={!isRequestPending && (!!hasPendingRequest || isOffline)}
            isLoading={isRequestPending}
            onPress={requestDomainAdminship}
        >
            <Button.Text>{translate('domain.accessRestricted.requestAdminAccess')}</Button.Text>
        </ConfirmationPage.Button>
    </ConfirmationPage.Footer>
</ConfirmationPage>

What this buys:

• shouldShow* disappears. A slot renders when it's provided.
• The *Style props disappear. style goes on the subcomponent that owns the region, so nothing has to be plumbed through the wrapper.
• The string/node pairs collapse. description + descriptionComponent become one <ConfirmationPage.Description>; same for cta + ctaComponent.
• Button content belongs to the caller — an icon, a badge, a DotIndicator, or a third button all become possible without touching ConfirmationPage.
• No visual drift. ConfirmationPage.Button pre-applies CONST.BUTTON_VARIANT.SUCCESS / CONST.BUTTON_SIZE.LARGE / styles.mt3 so 30 screens stay consistent without each caller repeating them. This resolves the sizing/styling trade-off raised in the original write-up: sizing stays owned by the component, not the call site.

Layout logic stays inside ConfirmationPage — the ScrollView + centering container at ConfirmationPage.tsx:111-158 and the FixedFooter at ConfirmationPage.tsx:159-188. Only content and state move out.

Scope

• src/components/ConfirmationPage.tsx — the component itself
• 30 call sites under src/pages render <ConfirmationPage on main and all need migrating

shouldShowButton            30     descriptionComponent      5
buttonText                  30     innerContainerStyle       5
onButtonPress               30     secondaryButtonText       4
heading                     30     onSecondaryButtonPress    4
description                 28     headingStyle              3
illustration                19     cta                       3
containerStyle              18     ctaComponent              3
descriptionStyle            12     footerComponent           2
illustrationStyle           10     is(Secondary)Button*      1 each
shouldShowSecondaryButton    6

Migration strategy

Incremental, mirroring the parent issue's approach so nothing lands as one 30-file PR:

1. Add the subcomponents alongside the existing props. ConfirmationPage renders children when present and falls back to the flat-prop rendering otherwise, so main stays green at every step.
2. Mark all 24 flat props @deprecated with a pointer to the slot that replaces each one.
3. Migrate the call sites in batches by area (the groups above are a reasonable split — roughly 5 PRs).
4. Delete the deprecated props and the fallback branch once no call site uses them.

Once the shape is agreed for ConfirmationPage, run the same audit over the other Button wrappers that flatten button state into their own props.

Context

• Follow-up from the review discussion on feat: add request access button to the domain access restricted screen: feat: add request access button to the domain access restricted screen #100319 (comment)
• Full-migration proposal and the decision to widen this issue: Slack thread