First up is routing. We said in Chapter 6, Practical – Monitoring Dashboard, that the route is a way of keeping part of the application's state in the URL. Another way of looking at this is that as the application changes through its various states, you are walking through the screens that the user would see as they interact with the interface.
By working out the various high-level states of our application, we can better visualize the user flow and establish the routes that we can employ in our code.
This is displayed straight after login and represents the default state of the main screen of the application before the user interacts with it. It looks as follows:
Route: /#home
The views will have the following state:
view.threads.Main.activeItem = 'threads'
If we're in portrait view, we'll use a card layout.
This means that the home state of the application needs to have the thread view as the active item:
view.main.Main.rightPane.hidden = true
In the initial state on a normal device, the user has neither selected a message nor has chosen to compose a new message. Therefore, there's nothing showing in the right-hand pane.
The route that handles requests for a new thread is displayed in the following command:
Route: thread/new
When the user presses the new message button, they are shown the composer view. The overall state changes as follows:
view.main.Main.activeItem = 'rightPane' view.composer.Composer.hidden = false view.messages.Messages.hidden = true
Remember that changing route doesn't mean that the state reverts to the initial state and then changes; we need to reset all things that could potentially have been shown by another route. In this case, if the user previously selected a thread, then the messages view would be showing, and we need to hide it when creating a new message.
The route to handle requests for a specific message thread is as follows:
Route: thread/:id/messages
It's triggered when the user selects a thread as follows:
view.main.Main.activeItem = 'rightPane' view.messages.Messages.hidden = false view.composer.Composer.hidden = true view.main.MainModel.currentThreadId = :id
Pretty much the opposite of a new message in which the messages are shown and the composer is hidden. The thread that was selected needs to be made available to the components that require it, in this case, the message view, so it can load the required messages.
The route to handle requests for a new message thread is as follows:
Route: thread/:id/messages/new
This is the final route in our application, and is used when a thread has been selected and then the user clicks on the "reply" button.
view.main.Main.activeItem = 'rightPane' view.messages.Messages.hidden = false view.composer.Composer.hidden = false view.main.MainModel.currentThreadId = :id
Similar to the "show thread" route, except that the composer is shown as well as the messages view.
Examining the paths a user can take through your application can be a very valuable way of making sure nothing is missing from your design. It also gives the site the benefit of understanding the state of your application at various points on the path and allows you to translate this into routes to restore that state.