Hi, Robert,

Thanks for reading!

It seems you are describing a case that requirements want the same BillPaymentComponent in another part of the same app and correct me if I’m wrong.
That’s a relatively large scale component, one that a route resolves to. We might call it a “Page”-host component.

Assuming I got it right, I agree with you that tying the UI with a concrete implementation is a bit of an antipattern. Here’s what I would do:

I would modify the UI component to depend on a PaymentProvider interface instead of the BillPaymentPage and have the page implement that interface:

Having said that I’ve found that the Page host component, the one that the route resolves to, is usually stable.

It seems the requirement you describe would be to have the same Payment UI component in a different place in our app. If business needs are exactly the same, we could use the exact same component, maybe under a different route.

In case the requirements are different then reusing the same large scale UI, “Page”-host component could also lead to an unwanted single point of failure result.

What do you think?