refactor(SDK-1127): extract CreatePaymentFlow and ViewPaymentFlow#2463
Merged
Conversation
…ing match `assertPaymentSummary` and the duplicate check in 93-payment-submit.spec.ts asserted on "Payment summary," which also appears on the review page's own totals grid, so the assertion could pass before submission actually completed. Assert the review heading disappears instead. Also give FlowRenderer's onEvent handler a real state update so e2e exercises the same re-render churn a partner app produces, instead of masking bugs behind a no-op handler.
…refactor (SDK-1127) Renders the full PaymentFlow tree — the only test layer that can catch a wiring-level bug between the hub and a future spoke, unlike the machine unit tests or e2e's happy-path-only coverage. Covers the history -> statement -> breadcrumb-back -> cancel path, breadcrumb navigation back to the list from both history and createPayment, and a forced parent re-render mid-flow, so the upcoming CreatePaymentFlow/ViewHistoryFlow split has a regression net before any code moves.
…spokes (SDK-1127) Carves the create-payment and view-history steps out of PaymentFlow into their own hub+spoke flows, mirroring the PayrollFlow/PayrollExecutionFlow pattern: each spoke owns its own robot3 machine and breadcrumb trail, prefixed with the hub's landing breadcrumb, and bubbles terminal events (exit, cancel, landing navigation) back up to the hub. Prepares the fourth spoke slot for the upcoming HistoricalPaymentFlow. Pure structural refactor — no behavior change, all events unchanged; the flow-integration and machine tests added alongside this confirm the split preserves the flat machine's exact transitions. Each spoke builds its machine via a lazy useState initializer rather than useMemo, and passes prefixBreadcrumbs straight into its trail without stripping onNavigate — both fix real regressions found in an earlier attempt at this same split (a useMemo keyed on an unmemoized breadcrumbs array silently reset in-flight flow state on re-render; stripped onNavigate broke "click breadcrumb to return to the hub"). CreatePaymentFlow and ViewHistoryFlow are marked @Alpha rather than promoted to public: PaymentFlow keeps composing them internally, but partners on the public surface still see the underlying blocks (CreatePayment, PaymentSummary, PaymentHistory, PaymentStatement) documented as before. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mariechatfield
changed the title
mariechatfield
commented
Jul 23, 2026
Contributor
Author
There was a problem hiding this comment.
This is the important new test. My first attempt at refactoring accidentally broke some navigation. The state machine unit tests passed because the logic for navigating on events remained; what was missing was firing the expects we expected and when.
These tests let us walk through more of the variations of navigation in a way that's cheaper/faster than a full e2e test but more thorough than purely a state machine test.
mariechatfield
commented
Jul 23, 2026
mariechatfield
commented
Jul 23, 2026
…spokes (SDK-1127) Adds hub-level integration coverage for the two remaining untested paths through PaymentFlow: submitting a new payment through CreatePaymentFlow to PaymentSummary, and entering/exiting the information-requests spoke via both cancel and done. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ntextual wrapper InformationRequestFormContextual never got the Footer static-property assignment that every other Flow-composed form uses, and the barrel export was missing Footer entirely. The response modal rendered with no Cancel or Submit button whenever InformationRequestsFlow drove it, and closing via the modal's X never notified a parent hub (e.g. PaymentFlow) either. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The flow has one spoke and a real exit, not a fan-out of spokes off a resting screen -- shape-wise it reads as a guided drill-in-and-back, not a hub. Also names the return edge explicitly (breadcrumb/navigate) instead of collapsing both directions under one label. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mariechatfield
force-pushed
the
refactor/marie/SDK-1127-test-driven
branch
from
July 23, 2026 19:39
2f0c29c to
c7082e0
Compare
mariechatfield
commented
Jul 23, 2026
| /> | ||
| ) | ||
| } | ||
| InformationRequestFormContextual.Footer = Footer |
Contributor
Author
There was a problem hiding this comment.
Latent bug that we found while adding information requests to the flow test 🙃
Aligns the view spoke's name with its sibling CreatePaymentFlow -- both are Payment-flow spokes of ContractorManagement.PaymentFlow, and the old ViewHistoryFlow name was the only one that didn't follow that pattern. Pure rename: no behavior change.
mariechatfield
changed the title
dmortal
approved these changes
Jul 24, 2026
mariechatfield
enabled auto-merge
July 24, 2026 21:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ContractorManagement.PaymentFlowremains exactly the same;ContractorManagement.CreatePaymentFlowandContractorManagement.ViewPaymentFloware new@alphaflows that represent the spokes / internal flows.post-refactor.mov
Changes
fb9173d6,2f3a2910) adds a flow-integration test layer against the current flatPaymentFlow— the only layer that renders the real component tree and can catch a wiring bug between hub and spoke — plus fixes two weak/no-op spots in the e2e harness that a prior attempt at this refactor needed but never landed.66f953ea) re-extractsCreatePaymentFlow/ViewPaymentFlowas spokes, mirroring thePayrollFlow/PayrollExecutionFlowpattern. Fixes two real regressions a previous attempt at this same split introduced: each spoke now builds its machine via a lazyuseStateinitializer (notuseMemo, which doesn't guarantee identity survives a re-render triggered by a bubbledonEventcall) and passesprefixBreadcrumbsstraight through without strippingonNavigate(which had broken "click breadcrumb to return to the hub").CreatePaymentFlow/ViewPaymentFloware marked@alpha, not@public— they exist to prep a 4th spoke slot for the upcomingHistoricalPaymentFlow, not because a partner asked for standalone entry points.PaymentFlow's public docs still describe the underlying blocks (CreatePayment,PaymentSummary,PaymentHistory,PaymentStatement) as before.ViewHistoryFlowtoViewPaymentFlow(9cee5ead) so it follows the same<Verb>Paymentpattern as its siblingCreatePaymentFlow..reports/,docs/reference/**,docs/guides/endpoint-*,sdk-app/generated-registry-data.ts) intentionally excluded — CI regenerates and commits those separately.Test plan
npm run test -- --run— 3559 passed, 1 expected failnpx tsc --noEmitcleannpx eslintclean (only pre-existing unrelated warnings)npm run buildcleannpx knipclean on new filesPaymentFlow.test.tsx, written against the old flat implementation, passes unmodified against the new hub+spoke code🤖 Generated with Claude Code