Now that we can describe the various states that our UI is in, we can begin to apply the logic that is required to move between these states. We will use the Mediator pattern to accomplish this. The purpose of the Mediator pattern is to define how a set of objects interact with each other, and it does this by injecting an object in-between the ones that affect each other. This means that the objects in question do not actually communicate with each other, they work against an interface. This promotes loose coupling between objects.

There are essentially two parts to the Mediator pattern. The first part is to define an interface that the Mediator can call in order to apply the changes that it needs. The Mediator, in this case, is communicating with our UI classes. In our application, we will need the Mediator to be able to signal the UI to either show or hide the side navigation panel, and show or hide the detail panel. The Mediator also needs to switch the show/hide button from a < chevron to a > chevron, depending on the current application state.

The second part of the Mediator pattern is the logic of how to move from one state to another. The Mediator itself will keep track of what state the application is in, and then coordinate UI actions in order to move from one state to another.

By defining an interface for these interactions, we are following object-oriented best practices, and shielding the Mediator code from the actual implementation of the UI changing logic. We can also code and test this Mediator logic without an actual UI in place.

Therefore, our interface for the Mediator class is as follows:

export interface IMediatorImpl { 
    showNavPanel(); 
    hideNavPanel(); 
    showDetailPanel(); 
    hideDetailPanel(); 
    changeShowHideSideButton(fromClass: string, toClass: string); 
} 

Here, we have distilled all of the UI changes required by our application into five functions. We can either show or hide the side navigation panel, show or hide the detail panel, or update the CSS class button.

Looking back at our work so far, we have simplified our business logic into two parts. First, we have defined the states that our UI will be in at any point in time, and second, we have defined the functions required to update our UI. We are already on the way to building a modular, object-oriented, easy-to-understand, and easy-to-maintain application. We will tackle the implementation of the Mediator logic a little later, after we have performed some housekeeping on our existing code.