Skip to content

feat(SDK-1129): add HistoricalPaymentsFlow - #2552

Open
mariechatfield wants to merge 2 commits into
mainfrom
feat/marie/SDK-1129/historical-payment-flow
Open

feat(SDK-1129): add HistoricalPaymentsFlow#2552
mariechatfield wants to merge 2 commits into
mainfrom
feat/marie/SDK-1129/historical-payment-flow

Conversation

@mariechatfield

@mariechatfield mariechatfield commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds HistoricalPaymentFlow, chaining CreateHistoricalPayment -> HistoricalPaymentSummary (mirrors CreatePaymentFlow's shape: two-state machine, lazy-init so in-flight state survives a host re-render, non-final terminal state so the summary screen stays interactive if not unmounted).
  • Wires it in as a fourth spoke off PaymentFlow: new contractor/historicalPayments/create event, a "Record a historical payment" CTA on the payments list, and a historicalPayment hub state that returns to landing on exit.
  • Exports HistoricalPaymentFlow publicly (@alpha) alongside its breadcrumb labels, and regenerates the derived API report / docs / i18n types.
flows.mov

Test plan

  • npm run tsc
  • npm run test -- --run src/components/Contractor/Payments (81 tests passing)
  • New HistoricalPaymentFlow.test.tsx covering the create -> summary chain and exit
  • Extended PaymentFlow.test.tsx covering CTA entry, the full create -> summary -> exit chain through the hub, and re-render resilience mid-flow
  • Manual click-through in Storybook / sdk-app

🤖 Generated with Claude Code

@mariechatfield
mariechatfield marked this pull request as ready for review August 11, 2026 20:50
@mariechatfield
mariechatfield requested a review from a team as a code owner August 11, 2026 20:50

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the one thing that's a bit weird. The components for HistoricalPaymentsFlow are marked alpha but this is live-updating the public PaymentFlow which feels... a bit weird. Should there be a way to mark an alpha feature as opt-in?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a similar situation with i9 in employee onboarding, I ended up just going with a prop that was available at the top level of the flow component. LIke withEmployeeI9 defaulted to false on the initial rollout. If you're concerned about releasing pre test fest, that might be a good way to keep it hidden while the test fest and fixes happen. Then when we feel ready we can remove the flag

You could also go more descriptive with the prop like withUnstableInProgressHistoricalPaymentsUseWithCaution or similar

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from slack discussion: removing the PaymentFlow changes and only adding new alpha surface area in this PR

@serikjensen serikjensen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! couple of things

  • Would recommend adding the boolean flag prop and defaulting it to false while we're rolling this out pre test fest (as described in slack)
  • We should align with Aaron on breadcrumb use, i think we're getting away from that so that could simplify some things in the implementation
  • Recommendation to update the state machine to properly re-create on company id change

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a similar situation with i9 in employee onboarding, I ended up just going with a prop that was available at the top level of the flow component. LIke withEmployeeI9 defaulted to false on the initial rollout. If you're concerned about releasing pre test fest, that might be a good way to keep it hidden while the test fest and fixes happen. Then when we feel ready we can remove the flag

You could also go more descriptive with the prop like withUnstableInProgressHistoricalPaymentsUseWithCaution or similar

Comment on lines +17 to +37
export const historicalPaymentBreadcrumbsNodes: BreadcrumbNodes = {
createHistoricalPayment: {
parent: null,
item: {
id: 'createHistoricalPayment',
label: 'breadcrumbLabel',
namespace: 'Contractor.Payments.CreateHistoricalPayment',
onNavigate: ((ctx: HistoricalPaymentFlowContextInterface) => ({
...updateBreadcrumbs('createHistoricalPayment', ctx),
})) as (context: unknown) => unknown,
},
},
historicalPaymentSummary: {
parent: null,
item: {
id: 'historicalPaymentSummary',
label: 'breadcrumbLabel',
namespace: 'Contractor.Payments.HistoricalPaymentSummary',
},
},
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth touching base with @aaronlee777 on the breadcrumb use here. I think breadcrumbs are generally something we're getting away from. He may also have an alternative for nav recommendation for the flow

Comment on lines +113 to +121
return createMachine(
'createHistoricalPayment',
historicalPaymentMachine,
(initialContext: HistoricalPaymentFlowContextInterface) => ({
...initialContext,
...initialBreadcrumbContext,
component: CreateHistoricalPaymentContextual,
companyId,
}),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might consider placing the machine creation in a useMemo here instead. Ex. if we got a new company id, we'd want to tear down the machine and create a new one

mariechatfield and others added 2 commits August 11, 2026 15:42
Chains CreateHistoricalPayment -> HistoricalPaymentSummary, mirroring
CreatePaymentFlow's shape exactly: two-state machine driven by
contractor/historicalPayments/created, lazy useState machine init (not
useMemo) so in-flight state survives a host re-render, and a plain
zero-transition summary state rather than a robot3 final() state, since this
can be mounted standalone and must not dead-end if the host doesn't unmount
it after completion.

Exported alongside its own breadcrumb labels; not yet reachable from
PaymentFlow.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ow export

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@mariechatfield
mariechatfield force-pushed the feat/marie/SDK-1129/historical-payment-flow branch from 6343b14 to 16ce490 Compare August 11, 2026 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants