Thieves Like Us

(Re)Learning Backbone Part 8

Brian Majewski — Tue, 24 Feb 2015 05:02:02 GMT

(Note: The code for this project at this point in our progress can be downloaded from Github at commit: c29507a245dce5f7cd3b900a72e8dbeac0fc3238)

A Little Cleanup

Back when we created the REST endpoints, we returned some "friendly" success messages. Without a UI, these made it easy to see when the requests went through. Now that we are going to be using them, let's have them return something more useful.

For GET /api/users and GET /api/users/:user_id, we already return an array or a single user, as appropriate. Let's do the same for POST /api/users and PUT /api/users/:user_id. For these, we will return the User that was either just created or was updated. There is no user we can return after a DELETE, so we can return an empty object. Our updated /app/routes/user.js code now looks like this:

var bodyParser = require('body-parser');  
var User = require('../models/user');

module.exports = function (app, express) {  
    var userRouter = express.Router();

    userRouter.get('/', function (req, res) {
        res.json({message: 'api is loaded'});
    });

    userRouter.route('/users')
        .post(function (req, res) {
            var user = new User();
            user.name = req.body.name;
            user.email = req.body.email;
            user.password = req.body.password;

            user.save(function (err) {
                if (err) {
                    if (err.code === 11000) {
                        return res.json({success: false, message: 'Duplicate username.'});
                    } else {
                        return res.send(err);
                    }
                } else {
                    res.json(user);
                }

            });
        })
        .get(function (req, res) {
            User.find(function (err, users) {
                if (err) {
                    res.send(err);
                }
                res.json(users);
            })
        });

    userRouter.route('/users/:user_id')
        .get(function (req, res) {
            User.findById(req.params.user_id, function (err, user) {
                if (err) res.send(err);
                res.json(user);
            })
        })
        .put(function (req, res) {
            User.findById(req.params.user_id, function (err, user) {
                if (err) res.send(err);

                if (req.body.name) user.name = req.body.name;
                if (req.body.email) user.email = req.body.email;
                if (req.body.password) user.password = req.body.password;

                user.save(function (err) {
                    if (err)res.send(err);
                    res.json(user);
                });
            });
        })
        .delete(function (req, res) {
            User.remove({_id: req.params.user_id}, function (err, user) {
                if (err) res.send(err);
                res.json({});
            })
        });

    return userRouter;
};

Adding Actions To Our User List

We're going to want to be able to Add a User, and Delete or Edit a specific user. Let's start with Delete.

Let's add a column to our table on the right side to hold user specific actions. Add a blank to our and a in our #each loop. In the add the following:

This will display a Delete button. We've added a data=id attribute to hold the User id. This will allow us to specify which User to delete. We've also added a js-deleteUser class to the button. We are using the js-* pattern for class names that indicate functionality as opposed to design.

Now, let's add the functionality to perform the delete in /app/users/listView.js. Under the el declaration, add an events block

events: {  
    'click .js-deleteUser': 'deleteUser'
},

On the left, we define an event and a CSS selector for the event, and on the right, a method to handle the event. In this case, we are trapping for a click event on any item with a class of js-deleteUser, and delegating to the deleteUser method to handle it. Let's create that method now.

deleteUser: function(e){  
    var self = this;
    var id = $(e.currentTarget).attr('data-id');
    var user = this.collection.get(id)
    user.destroy().done(function(){
        self.collection.remove(user);
        self.render();
    });
}

Here we ask the object that triggered the event for the value of its data-id attribute, and retrieve that user from our collection. We trigger the destroy method provided by Backbone, we will call our REST backend. When it is complete, we remove the user from the collection, and redraw the table.

Reload the app, and delete a user. If you don't have any to delete, you can either use the Postman extension to add some more, or, we can forge ahead and wire in an Add button.

We want to have a modal dialog popup with a form that will allow us to enter in a name, an email, and a password, along with a button to save it. With a little bit of configuration, we can use this same dialog to edit an existing user. To do the heavy lifting, we're going to add in a few libraries. Since we are using Bootstrap for our CSS, let's just dive in and grab the whole framework. We'll still only pull in what we need as we need it. We're also going to use a Backbone plugin to wrap the Bootstrap modal functionality so that we can easily interact with it from our views. Adding backbone.bootstrap-modal with bower will pull both libraries in.

We also want to incorporate data-binding. Data-binding is one of the big features that frameworks like Angular and Ember pitch as a benefit. We're going to get all the functionality they provide with much greater and explicit control of when we use binding and how for a lighter footprint on our page. For this, we will use stickit from the NYTimes. Install both these libraries with

bower install backbone.bootstrap-modal backbone.stickit --save

and update the require-main.js file

"bootstrap-modal": "../components/bootstrap/js/modal",
"backbone.bootstrap-modal": "../components/backbone.bootstrap-modal/src/backbone.bootstrap-modal",
"stickit" : "../components/backbone.stickit/backbone.stickit"

Let's once again update our list view, with an Add button at the top of the page and an Edit button next to the Delete.

/app/users/list.hbs

  
    Users
  

    {{#each users}}
        
    {{/each}}
      
    
    ID
    Email
    Name
    
    
    
            {{_id}}
            {{email}}
            {{name}}

ID	Email	Name
{{_id}}	{{email}}	{{name}}

Since we are using the same code for both editing and adding, we've added the same class, js-editUser to both. To the Edit button, we add a data-id attribute. If we were going to add any more actions, we might consider putting the ID on the row once for all the fields. For now, we'll stick with this.

Let's update our List view to trap for the new event.

events: {  
    'click .js-deleteUser': 'deleteUser',
    'click .js-editUser': 'editUser'
},

and

editUser: function(e) {  
    var id = $(e.currentTarget).attr('data-id');
    var options = id ? {title: 'Edit User', model: this.collection.get(id)} : {title: 'Add User'};
    console.log('options', options);
}

We don't have anywhere to send the user just yet, so we'll construct our options and log them to verify our event is wired in. Here we check for a data-id value on the element. If we have one, we are going to edit the user, so we set an appropriate title for our soon to be created dialog, and retrieve the user from the collection. If there is no data-id, like on the Add button, we set the title to 'Add User', and leave the model undefined. Reload your app and verify that we have all this working.

Creating our Dialog

Whether we are adding or editing a User, we will need a form with fields to enter data. Let's create a template for one, wrapped in the markup to create a Bootstrap modal dialog.

/app/users/single.hbs

This is mostly boilerplate Bootstrap code. Notice that we have assigned IDs to the form fields. We will use these to bind our data. Because we are binding our data, we don't need to use any template substitution for these values. We have also added a variable to hold our title at the top, and we added a js-saveUser class to our Save button. We'll use Bootstrap's built in functionality to cancel/close the modal when the user hits the Cancel or Close buttons.

To pair with our template, we will create a simple Backbone view. This view will handle binding our model data to the form fields and vice versa. It will also persist the data when the Save button is pressed.

/app/users/singleView.js

define(function (require) {

    'use strict';
    var Backbone = require('backbone');
    var mediator = require('mediator');
    var template = require('hbs!users/single');

    require('stickit');

    var User = require('users/model');

    return Backbone.View.extend({
        initialize: function (options) {
            this.title = options ? options.title : 'Please Set A Title';
            this.model = this.model || new User();
        },

        bindings: {
            '#name': 'name',
            '#email': 'email',
            '#password': 'password'
        },

        events: {
            'click .js-saveUser': 'saveUser'
        },

        render: function () {
            this.$el.html(template({title: this.title}));
            this.stickit();
            return this;
        },

        saveUser: function () {
            var self = this;
            this.model.save().done(function (response) {
                if (self.model.isNew()) {
                    self.model.set('_id', response._id);
                }
                mediator.trigger('users:userSaved', self.model);
            });
        }
    });

});

At the top, we require our dependencies. We also include stickit here. Since it is a plugin, we don't need to assign it to anything. In our initialize method, we set some default values if the options passed to us don't have them. We also create a new User if we need one, as is the case for when we are adding one.

The bindings block is new. This is how we configure stickit. In this simple example, we map our CSS selectors on the right to User model attributes on the left. Stickit can do a lot more than this so read the docs.

We set up a standard events entry to trap for the Save button.

In our render method, we render our template as normal, then call stickit to activate the bindings.

Finally, we create a saveUser method. We use Backbone's built in save functionality. This will determine if the User is new or being edited, and call the appropriate backend method. When we get a successful response, we update our object with an _id value if necessary, then fire off a message to let our list view know we are done. We do this so that the list view can manage the lifecycle of the dialog window, including the opening and closing of it.

Let's now go back to our list view and update it to manage the dialog window.

Add our new dependencies

var mediator = require('mediator');  
var SingleView = require('users/singleView');  
require('bootstrap-modal');  
require('backbone.bootstrap-modal');

Since we are going to be responding to message, let's wire that up:

initialize: function(){  
    this.bindPageEvents();
},

bindPageEvents: function(){  
    mediator.on('users:userSaved', this.userSaved, this);
},

userSaved: function(user){  
    this.modal.close();
    this.collection.add(user);
    this.render();
}

When we receive a message that the user has been saved, we close the modal that we will soon create, add the passed user to our collection, and rerender the table. If the user has an id that is already part of our collection, it will update itself, otherwise it will add itself.

Finally, lets create the modal. Let's go back to our editUser method

editUser: function(e) {  
    var id = $(e.currentTarget).attr('data-id');
    var options = id ? {title: 'Edit User', model: this.collection.get(id)} : {title: 'Add User'};
    var modalView = new SingleView(options);
    this.modal = new Backbone.BootstrapModal({content: modalView}).open();
},

We've removed the logging. We instantiate the view that holds our form fields with the options we've created. We then wrap that view with a Backbone.BootstrapModal view and open it. Simple as that. Reload your app and try adding and editing some Users.

Let's make one final cosmetic tweak. Since the last column in the table is always the same visually, let's turn sorting off for it. Pass in the following options when we construct the DataTable

this.$('table').DataTable({  
    "aoColumns": [
        null,
        null,
        null,
        { "bSortable": false }
    ]
});

Next Steps

We now have a relatively full featured CRUD management tool. We could easily add new entities by following the patterns we have set up here. Could we have generated these much quicker with an all encompassing framework? Sure. The use of small focused plugins, however, has kept our boilerplate code to a minimum and we have had full control over every line of code.

The last big piece that we are going to add that I consider mandatory for a starter app is authentication. We will put all the User editing functionality behind a login screen and see how to hold and use application wide data, such as the currently logged in user.

(The code at this state in the project can be checked out at commit: 8a19651c576968b29f143d271147b0b288ca63a7)

(Re)Learning Backbone Part 7

Brian Majewski — Sun, 22 Feb 2015 23:13:29 GMT

(Note: The code for this project at this point in our progress can be downloaded from Github at commit: e55dbc2be4ab5e8ce883ad7e397654e346f5d135)

Getting Our Users and Displaying Them

Today, we are going to access our REST backend using Backbone's Collection object and display the results on screen. To do this, we'll add a link to our navigation section in the header, create a view to display the results, and update the router to include those results in our page layout.

Navigation

Let's go ahead and update /app/page/header.hbs'. Between the navbar-header div and the navbar-right div, add

  
     Users

You'll notice there are some 'fa' classes in there. That's because I added FontAwesome to the mix. Use bower to install it

bower install font-awesome --save

then add the CSS to your index page

For our navigation, we used a standard A anchor tag with a URL that mimics our REST API URL. There is no technical need to keep them the same (and in fact they are not - our UI does not expose the /api portion) but keeping them aligned is a useful organizational tool. You should also notice that the URL begins with a hash. Backbone, by default, uses Hash URLs. They are more backwards compatible with older browsers that do not support Push State. Normal URLs are preferred and we'll convert this one later on to take advantage of them.

Creating our Model and Collection

Backbone provides some base objects that we can use to contain our model object (a User) and a collection of them. By giving these objects a URL, they will know how to interact with a standard REST API to retrieve and persist the objects. Let's create them now.

/app/users/model.js

define(function (require) {

    'use strict';
    var Backbone = require('backbone');

    return Backbone.Model.extend({
        idAttribute: '_id',
        urlRoot: '/api/users'
    });
});

Here we are setting two properties, idAttribute, which lets Backbone know to use the MongoDB generated value _id as the id for the object, and urlRoot, which tells it the base URL to use when constructing REST calls.

/app/users/collection.js

define(function (require) {

    'use strict';
    var Backbone = require('backbone');
    var Model = require('users/model');

    return Backbone.Collection.extend({
        model: Model,
        url: '/api/users'
    });
});

Again, we are setting two properties. model is the Backbone model of the objects in the collection - in our case the User model. url is the REST API url to retrieve the collection from.

Displaying The Collection

In my apps, I have two different ways to think about displaying a collection of objects. In cases such as our User collection, it is primarily a tabular display of data. It can show all or a portion of the model's properties, and usually presents actions such as Edit or Delete. In cases such as these, I don't expect the collection to be changing underneath the user without explicit interaction.

Other collections, however, could be more dynamic. Suppose you are looking at a live stream of tweets that are getting continually updated. Perhaps the collection represent pieces in a game that are getting moved around based on rules. In cases like that, we will want to construct a collection view that delegates a lot of control to individual model views and can respond to events that they generate.

For CRUD screens like the one we are going to build, we can use the DataTables library to easily add features like sorting, pagination, and filtering to our view.

Install DataTables and a convenient plugin to mix it in with our Bootstrap theme:

bower install datatables datatables-bootstrap3-plugin --save

update require-main.js with the following entries

"datatables": "../components/datatables/media/js/jquery.dataTables",
"datatables-bootstrap3": 
    "../components/datatables-bootstrap3-plugin/media/js/datatables-bootstrap3"

and add the CSS to index.html

Now let's create our template and view

/app/users/list.hbs

  
    Users
  

    {{#each users}}
        
    {{/each}}
      
    
    ID
    Email
    Name
    
    
            {{_id}}
            {{email}}
            {{name}}

ID	Email	Name
{{_id}}	{{email}}	{{name}}

A fairly straightforward table template. We'll use Handlebars #each directive to loop over the users and display a row for each.

/app/users/listView.js

define(function (require) {

    'use strict';
    var Backbone = require('backbone');
    var template = require('hbs!users/list');
    require('datatables');
    require('datatables-bootstrap3');

    return Backbone.View.extend({
        el: '#content',
        render: function(){
            this.$el.html(template({users: this.collection.toJSON()}));
            this.$('table').DataTable();
            return this;
        }
    });

});

Some differences to call out. We've required our DataTables related libraries but did not assign them to a variable. Since they are plugins to jQuery, we won't need to access them on their own.

In our render method, we take our collection of users, convert them to JSON and pass that in as users to our template to render. This is the object that the #each directive is looping on in our template.

Finally, we activate the DataTables functionality by attaching it to the table in our view.

The only thing that may not be clear is where the collection we convert to JSON is coming from since we did not define it in this view. We could have instantiated it here, and asked it to fetch itself. We would then have to coordinate with our Page view to tell it that the collection was ready, and to rerender it. In some cases, such as when many different backend calls will need to be made to display a page, this will be an appropriate solution. For this simple case, we'll have the router grab the collection and prepare the view before we hand it off to the main Page. This way, it will be ready to render right away. Let's take a look at that:

/app/router.js

routes: {  
    '': 'home',
    'home': 'home',
    'users': 'users'
},

users: function() {  
    console.log('routing - users');
    require(['users/collection', 'users/listView'], function(Collection, View) {
        var collection = new Collection();
        collection.fetch().done(function(){
            mediator.trigger('page:displayView', new View({collection: collection}));
        });
    });
},

We've added a route for users that is handled by a users method and the users method itself. We require the users view and collection. We instantiate the collection and fetch the contents. When the contents are retrieved we add them a new view and send a message off to the page to render the view.

Next Steps

In the next installment, we'll some actions to add, edit, and delete users.

(Re)Learning Backbone Part 6

Brian Majewski — Sun, 22 Feb 2015 00:14:37 GMT

(Note: The code for this project at this point in our progress can be downloaded from Github at commit: 82df0f2fd5bdc91d5599aa1c40faacca38766327)

Deep Breath

This is going to be a lengthy installment. We've done a lot of setup, including creating a fully functioning server with REST endpoints and wiring up our front-end dependency management. Today, we are going to make a lot of small steps that when put together will give us a completely functional single page application with routing, an event bus, and dynamic views. Let's start by adding our third party dependencies.

Bower

We're going to be installing Backbone, which has a dependency on Underscore and jQuery, for our MVC framework and Handlebars for our templating framework. We'll also be adding a couple of plugins for Require that will make loading our templates easy.

To install the whole lot, run:

bower install backbone underscore jquery handlebars requirejs-text require-handlebars-plugin --save

When complete, you'll see your bower.json file has been updated and a bunch of new libraries has been installed under public/components. These libraries all have different directory structures and since they don't live under our app directory, we are going to create shortcuts for Require to use when loading them.

In our require-main.js file, add the following entries to the paths block;

paths: {  
    "jquery": "../components/jquery/dist/jquery",
    "underscore": "../components/underscore/underscore",
    "backbone": "../components/backbone/backbone",
    "handlebars": "../components/handlebars/handlebars.amd",
    "text": "../components/requirejs-text/text",
    "hbs": "../components/require-handlebars-plugin/hbs"
}

These are the paths to the main Javascript file in each of the libraries. You'll notice each is prefixed with ../. This is because we set our baseUrl to app, so we need to adjust for that. We've also left the .js off the file name. If you look in the libraries, you'll see some come with pregenerated minified versions. At this point in development, I prefer using the full version to make debugging easier. We can worry about optimization later. Also note, we used the .amd version of Handlebars. This is the module format that Require uses so picking this flavor will let us work with it without having to create any shims.

Routing and Our Home Page

The heart of a single page application is the routing. It is responsible for interpreting the URL and displaying the correct information on the screen. Later, it will also be responsible for ensuring that our user is authenticated and redirecting them to login if needed.

To begin, we are going to create a single route, that displays our main page layout. The layout will incorporate a container for sub-views to be displayed in and a header view to contain our navigation elements. We'll also use a partial template to display a footer at the bottom of our page. To help avoid memory leaks, we'll extend the standard Backbone View with some utility methods to clean itself up when it is closed.

All of these pieces are fairly intertwined so there is no obvious place to start. Let's start with a bit of plumbing that we will use throughout our whole app, our event bus.

Event Bus

Backbone.Events is a mixin that can be added to any object and enables that object to listen to and trigger events that other objects can listen for and react to. While, most Backbone objects have this mixin already, I find it is easier to create a specific object that we can explicitly use as an event bus.

/app/mediator.js

define(function(require){

    'use strict';

    var _ = require('underscore');
    var Backbone = require('backbone');

    return _.extend({}, Backbone.Events);

});

Simple really. We create an empty object, mixin the Events, and return it. Now, anywhere in our code we want to deal with messages, we can get a reference to this mediator and use it. There are some other interesting message patterns we may be interested in down the road, such as Commands and Requests. You can look at the Backbone.Radio plugin if your app needs these features.

Home Page

Create a page directory under app to hold the related files. We'll be using the 'pods' method of organizing our files that has become popular with the Ember crowd. It will let us keep all the information for a given feature together, as opposed to organized by function(controllers, views, etc.).

Create the following files:

/app/page/pageTemplate.hbs

  
  
{{> ./footerTemplate}}

/app/page/headerTemplate.hbs

  
    
        
            
                relearning backbone
            
            
                [Navigation Elements]

/app/page/footerTemplate.hbs

Relearning Backbone - http://brianmajewski.com

In the main template, we define three divs that will contain our header, main content, and footer. Since the footer is going to be static content, we could have easily included it in the page but this is a way to validate that partial templates are being included.

For now, there is no functionality in the header, so let's create a very simple Backbone view that renders the template.

/app/page/headerView.js

define(function (require) {

    'use strict';

    var Backbone = require('backbone');
    var template = require('hbs!page/headerTemplate');

    return Backbone.View.extend({
        el: '#header',

        render: function(){
            this.$el.html(template());
            return this;
        }
    });
});

There is that define(function (require){}); syntax again. I always include 'use strict'; as a matter of habit. Next, we use Require to include the Backbone library and the template. Note the syntax for the template: hbs!page/headerTemplate - hbs! tells require to use the hbs plugin we configured earlier, followed by the path to the template. It assumes a .hbs extension, but can be configured to accept others.

The rest is simple Backbone view stuff. We define the page element to attach the view to (el: '#header'), and then we define the render function, using the template as is to generate the html. As a matter of course, we will always return a reference to the view when we render it.

Now, let's create the containing Page view that will hold the header and other content views.

/app/page/pageView.hbs

define(function (require) {

    'use strict';
    var Backbone = require('backbone');
    var mediator = require('mediator');
    var template = require('hbs!page/pageTemplate');
    var HeaderView = require('page/headerView');


    return Backbone.View.extend({
        el: '#page',

        initialize: function () {
            this.contentView = null;
            this.bindPageEvents();
        },

        render: function () {
            this.$el.html(template());
            this.headerView = new HeaderView();
            this.headerView.render();
            return this;
        },

        bindPageEvents: function () {
            mediator.on('page:displayView', this.displayView, this);
        },

        displayView: function (view) {
            if (this.contentView !== null) {
                this.contentView.close();
                this.contentView = null;
            }

            this.contentView = view;
            if (this.contentView) {
                this.contentView.render();
            }
        }
    });

});

This is very similar to the header. We set it's element to #page. In our render method, we instantiate the HeaderView and render it as well. In the initialize method, we create a variable to hold our content views, and set up the view to listen to messages. In bindPageEvents, we listen on the mediator for the message page:displayView and when we get it, we call the displayView method. Here, we clean up any existing content view and render the one passed to us with the message. One non-standard thing we are doing here is calling .close on the content view. Backbone has a remove method which does something similar but we are going to be a bit more aggressive in cleaning up our code. We'll add this code in when we update our main.js file.

To test this out, we need a content view. Go ahead and create the following files to provide a simple Welcome view.

/app/welcome/template.hbs

  
    WELCOME TO OUR APPLICATION

/app/welcome/view.js

define(function (require) {

    'use strict';
    var Backbone = require('backbone');
    var template = require('hbs!welcome/template');

    return Backbone.View.extend({
        el: '#content',
        render: function() {
            this.$el.html(template());
        }
    });

});

Now we need a way for the application to display this view when we start up the app. Let's go ahead and create our router.

/app/router.js

define(function (require) {

    'use strict';
    var mediator = require('mediator');
    var Backbone = require('backbone');
    var PageView = require('page/pageView');


    return Backbone.Router.extend({
        initialize: function () {
            this.pageView = new PageView();
            this.pageView.render();
            this.bindApplicationEvents();
        },

        routes: {
            '': 'home',
            'home': 'home'
        },

        home: function () {
            console.log('routing - home');
            require(['welcome/view'], function (View) {
                mediator.trigger('page:displayView', new View());
            });
        },

        bindApplicationEvents: function () {
            mediator.on('router:navigate', this._navigate, this);
        },

        _navigate: function (context) {
            console.log('routing - trigger to ', context.route);
            this.navigate(context.route, context.options);
        }
    });

});

Let's break this down in chunks.

In our initialize function, we instantiate our Page view and render it to the screen. At this point, it has its header and footer but its content view is empty. Our router will fill in different views based on the URLs we visit. We also tell it to bindApplicationEvents. You'll see this pattern repeated. I will have the initializer of a class setup the messages/event bus for the messages it is interested in receiving. In this case, we are listening for a router:navigate message. This will allow other parts of our application to change where we are in our app without having a direct reference to the router.

In our routes object, we set up two paths, '' and 'home' that will route us to the home function.

In our home function, we require our Welcome view, which is the content view we want to display when someone hits our home page, then fire off a message, with the view attached, that our page is listening for.

Turning It On

The last step we need to take is to turn on the router. Let's update our main.js file.

/app/main.js

define(function (require) {

    var Router = require('router');
    var mediator = require('mediator');

    var router = new Router();
    Backbone.history.start({pushState: false});

    if (Backbone.history.fragment === '') {
        mediator.trigger('router:navigate', {route: 'home', options: {trigger: true}});
    }
});

Here we simply instantiate our Router, and tell Backbone to start managing our history. We've also added a little helper to ensure that when a user comes in the first time, with no URL fragment, such as /users/123, that we send them to the home page.

Fire up the server and refresh your page. You should see our fully composed page.

Extending Backbone
Remember, we wanted to add some functionality to ensure that Views we close release all their objects and events as to avoid memory leaks.

In our main.js file, under our require declarations, add the following code:

_.extend(Backbone.View.prototype, {  
        // Handle cleanup of view.
        close: function () {
            if (this.beforeClose) {
                // Perform any cleanup specific to this view.
                this.beforeClose();
            }

            if (this.model) {
                // Remove all callbacks for this view's model.
                this.model.off(null, null, this);
                this.model = null;
            }

            // Something else might be named 'collection' so also check for the
            // existence of `off`
            if (this.collection && this.collection.off) {
                // Remove all callbacks for this view's collection.
                this.collection.off(null, null, this);
                this.collection = null;
            }

            // Remove all delegated events.
            this.undelegateEvents();
            this.off(null, null, this);

            // Remove all markup.
            this.$el.empty();
        }
    });

Here we extend the base View definition to add our close method. This will call a beforeClose method on a view, if it has one, for view specific cleanup. If the view has a model or collection associated with it, it turns off the model/collections's events and clears the model/collection. It then turns off the view's events and removes the contents from the DOM.

Next Steps

In our next installment, we'll create a view that retrieves our users from our REST backend and displays the results.

(The code at this state in the project can be checked out at commit: e55dbc2be4ab5e8ce883ad7e397654e346f5d135)

(Re)Learning Backbone Part 5

Brian Majewski — Sat, 21 Feb 2015 04:34:43 GMT

(The current code base can be checked out here)

Front End Build

Often at this point in a project, I will get derailed. I'll start thinking about dependency management, should I use Grunt or Gulp or Broccoli or ... to build the project, module definitions, and the like. The combination of all these options just multiplies and I'll spin until I lose interest in the project for awhile.

Tasks like minification and image optimization and static analysis are important parts of a production application but we still haven't written one line of front end code. In the spirit of XP, I did the simplest thing possible that still works.

My requirements: I wanted to declare my Javascript dependencies on the fly. I always forget to add them individually to my index.html file. I want to declare them explicitly so that different sections of the code could be loaded independently when it comes time to optimize the app. This also has the side benefit of allowing my IDE to perform better autocompletion. I wanted all of my assets to be accessible from the simple web server we created earlier without a separate deploy step. Once we have a working app, we can then go back and figure out how to serve up the bare minimum.

To accomplish all of these tasks, we are going to use two tools: Bower and RequireJS. Bower will handle the management of third-party libraries and RequireJS will handle our dependency management and loading of files. There are other options, especially for RequireJS, such as Browserify. Feel free to explore them and pick one you are comfortable. The way you modularize your code will be a part of every file you write, so be happy with your choice.

Bower

Bower, like Node's NPM, allows you to automatically retrieve libraries from the net, and manage them and their dependencies. To install it, run

npm install -g bower

One quick customization we are going to make is where Bower stores its dependencies. Typically, we would keep them at the same level as our node_modules dependencies, and use a build tool to copy the specific JS and CSS files we need into our app. To avoid this, we will store our dependencies under our public directory so that our Node server can serve them up directly. This has the side effect that ALL files that come with the packages are accessible, such as READMEs and package files, but until we have a working app, this is a reasonable trade off. In your project directory, create a file called .bowerrc with the following contents:

{
    "directory":"public/components"
}

With this complete, run bower init, answer the questions and finally end up with a bower.json file that looks similar to:

{
  "name": "relearning-backbone",
  "version": "1.0.0",
  "homepage": "https://github.com/bmajewski/relearning-backbone",
  "authors": [
    "Brian M "
  ],
  "license": "MIT",
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "public/components",
    "test",
    "tests"
  ]
}

We're now set up to use Bower to pull in our other dependencies, including RequireJS.

RequireJS

To effectively use RequireJS, you really should go and read through the docs once or twice first. Go ahead, I'll wait. Done? Ok - It may not make a bunch of sense if you are new to this type of module management. Hopefully, as we work with it, it will become clearer.

In a nutshell, Require (I'm going to drop the JS from here on out) will allow us to specify just one Javascript requirement in our index.html file. From there out, it will dynamically load additional files as we need them without us having to explicitly add them.

To set this up, we'll update our index.html and create a configuration file for Require. To install Require, run:

 bower install requirejs --save

If you look under public/components, you'll see the newly installed package.

There are differing opinions on where to put Javascript declarations and how they effect initial download and rendering of your home page. For simplicity, we'll place our declaration in the of our document, beneath our styles.

  
    
    
    Relearning Backbone

As you can see, we've added a non-standard attribute to our script tag: data-main="require-main.js". This tells Require where to read its configuration information.

Go ahead and create the file require-main.js under public, with the following contents:

requirejs.config({  
    baseUrl: "app",

    paths: {

    }
});

require(['main']);

This is (almost) as minimal of a config file we can use and have it still be useful. At the top, we call config on requirejs and set some properties. baseUrl is where require should look for all files we haven't explicitly defined. paths are those explicitly defined files (and is empty for now). Next, we invoke require with an array of files we need to load. Typically, you would declare those files, and then a function, assigning those files to variables, and do something with them, such as:

require(['moment'], function(moment){  
    moment.format();
});

which would load the Moment library and display a formatted datestamp.

In this case, we are telling it to load the file main and process its contents. Our main file won't return anything - it will actually load up our application and start it up. Since we have't defined main in the paths block above, Require will look for app/main.js, so let's create an app directory and a main.js file with the following contents:

define(function (require) {  
    console.log('require module loading working');
});

All of our Javascript files will have this basic format: a define function that takes require as an argument. We'll be able to use this parameter later to load other files.

If you reload index.html, you should be able to see our message in your console window. This let's us know that we have Require wired in and loading our modules.

Spit And Polish

Before we get into the meat of designing our home page and screens to access the user data, I want to add a little bit of styling to the app. I find that if I leave things a little too "raw" I'll waste time trying to clean them up a bit. At this point I would usually grab Bootstrap to provide a simple clean interface. But... should I use the plain CSS, or maybe the LESS or the SCSS... Do I need to add a CSS preprocessor to my build pipeline? What about all the Javascript components, should I add them in too? Will they conflict with the stuff I want to write later? Oh hey, what about trying Susy for a grid layout? And on and on it goes. Once again - DERAILED Here is what I do now. I go to Bootswatch, pick a color theme that I like in the moment, download the CSS file, put it in assets/css, add it to my index.html file and I am done with CSS until it comes time to actually build my app and its feature set.

Next Steps

With our package management and module loader in place, we're ready to start building out our client application. Next time, we'll create a simple router, a message bus, and main layout that will allow us to swap different content views in as needed.

(To grab the code at this point in the series, checkout commit: 82df0f2fd5bdc91d5599aa1c40faacca38766327 from Github)

Thieves Like Us

(Re)Learning Backbone Part 8

UsersAdd User

{{title}}

(Re)Learning Backbone Part 7

Users

(Re)Learning Backbone Part 6

WELCOME TO OUR APPLICATION

(Re)Learning Backbone Part 5

Users