A View on Marionette

In our last tutorial post, we covered how to set up your base application. It’s now time to cover how I like to set up some simple Views and how they pull data from my backend server.

The Backend

Our application will typically have a back-end server created and ready to integrate with. For simplicity, we’ll use a simple note-taking app with two endpoints: List/Create a note and Retrieve/Update a note.

List/Create

Endpoint: /notes/

[
  {
    "id": "note-abc",
    "header": "Grab the shopping",
    "body": "* Milk\n*Bread\n*Ham\n*Cheese"
  },
  {
    "id": "mynote-cdf"
    "header": "",
    "body": "It's my turn to pick the kids up from school"
  }
]

Retrieve/Update

Endpoint: /notes/<id>

{
  "id": "note-abc",
  "header": "Grab the shopping",
  "body": "* Milk\n*Bread\n*Ham\n*Cheese"
}

Building Our App

Our Application structure — the boxes in Red are are focus for this blog

Now we know what our server accepts, it’s time to build our application for taking notes. Before starting, I’m going to assume you’ve read my previous post on A Basic Marionette App and have a non-routed application skeleton.

Our structure this time round fills in the views, models and collections portion of our app. The focus of this post is around how to wire your views together to present — and modify — the data to your users.

Models and Collections

s

We’ll first need to map our models/collections onto the server implementation above.

When building an application, we should always extend the default Backbone Model and Collection classes with your own. Backbone is built very heavily on MVC so make the best use of it in your applications to get the best out of Backbone and Marionette.

In future posts, I’ll be outlining testing strategies for your Marionette applications which will rely very heavily on using Models to handle your business logic.

Root View

I like to keep the Root view as simple as possible and ensure it only handles setting up and displaying the top-level views of our application. In this case, we only have a single top-level view but more complex applications will include navigation hooks or responding to routing. I’ll go into more detail in a future blog post. For now, let’s focus on creating our Root:

Our Application Views

It’s now time to start creating our views. We need two main files: list.js and detail.js that will show our list and detail/edit views respectively.

List

The list view will be the main display the user sees when they first log in. The parts worth noting are the child event chain of note:view to show the individual note for editing. Note we’ve used a childViewEvents at the top-level to change the arguments passed to the top. This is because the default Marionette triggers pass the triggering View into the function call which needs to be stripped for the parent view.

Detail

Here’s where things get a little more interesting — we actually get to create new notes and save them to the server. We have an events attribute that wires up our view to model.save() the contents of our form. The submit key simply references the jQuery submit event.

How It All Works

A visual representation — Methods are in Red and Events are in Purple

I’ll quickly cover the overall thought process I apply when building up application views. The basic principle is Call Methods Downwards, Push Events Upwards.

This principle avoids circular references and makes it possible to re-use views, models and collections elsewhere in our application with minimal changes.

What’s Next?

Over these two blog posts, you should have pretty much all the building blocks you’ll need to make most applications. Over the course of the next few weeks, I’ll focus on some ways to expand and simplify building applications including:

• How to handle cross-app communication using the Radio
• Showing views based on the URL accessed with the Router
• Different approaches to templating

If you have any preferences, you can reach me on Twitter @scott_walton and I’ll see what I can do.