Fancy working with a small team remotely? SupportBee is hiring developers!
Take a look at our jobs page

Chapter 5

Building the Ticket View

The Mockup

Like the previous chapter, let's start with a quick mockup

Mockup of the Tickets View

As you can see in the mockup, we want to make a simple ticket view with a list of replies and a text box to post a new reply. Let's get started

Ticket View

Since we have already defined SB.Models.Ticket model, we simply need a SB.Views.Ticket view. Here's the code.

Just like the TicketList view, we render a template, once again passing in a json to populate the data. The template looks like this

Apart from the ticket's details, the template also has empty divs for rendering replies and the new reply box. Let's work on rendering the replies.

The Reply Model

To be able to fetch and render replies, we first need a simple model

Apart from the name attribute (needed for unwrapping the JSON responses), we don't to define much in this model - not even the urlRoot property.

The Replies Collection

Since a ticket could have several replies, we need a collection to fetch the replies from the server

Since the API endpoint for replies depends on the ticket_id, we define a url method that will return the correct endpoint for making API calls.

The Reply View

While we can code up the logic for rendering the replies in the ticket view, it's better to create a new view and initialize it in the ticket view. This way, as the reply view grows over time, it won't bloat up the ticket view. It's very important to break up your application into screens and then breakup each screen into several views that can be coded and tested individually. Here is the code for the reply view

The template

Fetching Replies and Rendering Them

Now that we have the model, collection and view coded up, it's time to tie everything up together. We'll be extending the SB.Views.Ticket class to add this functionality. The buildView method in the ticket view calls renderReplies and all we need to do is define that method

Just like the last chapter where we rendered a collection of tickets, we create a new ReplyList collection, bind to the reset and addOne event and fetch the collection. Once the data is available, resetReplies will be invoked (thanks to the event binding). We then go ahead and iterate over all the replies and render them and append them to the view one by one. We append each reply to the replies_list div which was defined in the ticket view template.

Hopefully you are starting to see a pattern by now. If we have the data we need, we can simply use it and render a template. However if we need some data from the server, we setup an event handler before making a fetch call and the rendering happens whever the data is available.

Opportunities for Refactoring

While we did create a Reply view to hide away the logic of rendering a ticket, we are still doing a lot of work for rendering replies in the ticket view. Initializing the SB.Collections.ReplyList collection, binding to events and defining the handlers should ideally happen in a ReplyList view and the only thing that the Ticket View should be doing is initializing the ReplyList. Whenever you have a complicated view, it's a good idea to look for opportunities for refactoring the view.

That's all for this chapter. In the next chapter, we'll look at posting data to the server as we code up the new reply box.

Tell Me What You Think!

What else would you like to see? What do you think is missing or not needed?

comments powered by
Disqus