What are OOP software design patterns for managing identical React.js class hierarchies?

I am making a change to my React project that will result in a lot of similar classes, arranged in identical class hierarchies. I'm wondering what alternative organization I could use for my code.

The product currently shows a screen that is displayed on a storefront terminal, that both the store clerk and customer will interact with (reading a contract together, collecting signatures from both parties, etc.) The incoming change is to allow a two-monitor setup, where the clerk's monitor will control the workflow and the customer's monitor will follow along and ask for input when necessary. Single-monitor mode will still be supported.

The code currently has a main contract signing window, with visual components like the document viewer, the signature capture panel, a panel with contract details, etc. I imagine that when the two-monitor feature is completed, I will have three nearly-identical class hierarchies (or perhaps more accurately, identical object compositions). Similar components exist for the same purpose and are visually identical, but have different behavior.

MainWindow has a DocumentViewer, and a SignaturePanel, and a DetailsPanel  
ClerkWindow will have a ClerkDocumentViewer, and a ClerkSignaturePanel, and a ClerkDetailsPanel  
CustomerWindow will have a CustomerDocumentViewer, and a CustomerSignaturePanel, and a CustomerDetailsPanel  

I'm worried about the complexity growth of this pattern. When more components get added to the product, we'll need to implement three versions of each component; and, if we add another "mode", we would have to implement a new version of every existing component.

Additionally, the Main components and the Clerk components are very similar, because they have lots of controls for the user to interact with; but the "Customer" components have much less interaction. I'm not sure how to effectively share code between two of the three components. Part of the reason it seems difficult to organize correctly is because these are Typescript React components that must have typed state and props. If I were to have the different DocumentViewer components (for example) all inherit from a common superclass, I would either inherit unused state/props in the Customer components, or I would have duplicate code managing the common state/props of Main and Clerk components.

I've considered having a single DocumentViewer (etc) class with a mode property that controls how the component acts on different monitor setups, but the components will end up filled with switch statements, which indicates that I want some sort of polymorphism like described above.

What design patterns exist to manage these parallel class hierarchies? Are these patterns compatible with React-style state/prop management? Are there some sort of mix-in/module features of React/Typescript to allow well-organized sharing of state/props to a subset of sibling classes?