How Change Events Are Triggered In Backbone

I was having trouble understanding the various states that a given Backbone model, and all it's attributes, might be in. Specifically, how does an attribute change, and trigger the change event for that attribute. The change event isn't triggered when the model is first created, which makes sense because the model had to previous state. In other works, creating the model also creates a state machine for the model attributes. However, this can be confusing if you're adding a new attribute to a model.

Ensure Backbone View Is In The DOM

A nice aspect of Backbone views is that they're guaranteed to have an element. This takes place before the view constructor is called. Even if you don't supply any element details, such as the tag name, the element id — there will always be a div element. However, one thing you have to always remember is the add the element to the DOM. While the view ensures the element gets created, it doesn't ensure that the element is attached to the DOM. This is actually a good thing, because you don't always want to be forced to be working on an element that's in the DOM.

Backbone: How To Define Model Properties

Backbone models are kind of like plain JavaScript objects in that they have attribute names mapped to attribute values. In fact, you generally instantiate models by passing in a plain JavaScript object to the constructor. The difference, however, is in how you read and write Backbone model attributes. There's the set() and the get() method — an indirection not exhibited by plain objects.

Filtering Models When Cloning Backbone Collections

Filtering collections is fundamental to most Backbone applications. This is generally done within the context of a view. The view needs to display some subset of the collection. It selects the models it needs, by calling the where() method on the collection. This gives us an array of model elements. However, the downside with where() is that once you call it, you're now working with an array of models — not a collection of models.

Building Collections Using Lodash Invoke

The Lodash invoke() function does more than simply iterate over a given collection, calling the given method on each object. It actually stores the result of each method invocation, effectively building a new collection. This is a powerful idea, especially when it comes to chaining Lodash functions together.

Determine If Backbone View Has Rendered

I've encountered some tricky situations where I'm not sure if my Backbone view has made it's way into the DOM yet. In other words - how can I tell whether my view has been rendered or not? This situation can lead to some really subtle bugs. For example, some other JavaScript in your view expects the view element in the DOM. But when it's not there, the failure mode is anything but intuitive.

Cleanup Events With Backbone Routers

Backbone routers allow you to listen to route events. These are triggered when one of the defined paths in the router matches the URL. For example, the paths of your application can be statically defined and named in the routes object. The route events triggered by the router use the route name — route:home, or route:help. What's nice about this is that different components can subscribe to router events. This means I don't have to define all my route handling code in one place — each component of my application is able to encapsulate it's own routing logic. One piece of the puzzle that's missing is cleaning up my views once the route that created them is no longer active.

Too Many Views

It's tempting, given that Backbone affords developers such freedom in composing their applications, to create too many views. What might not seem like too many at first, probably is. There's simply no value in drilling down, ten levels, into the DOM hierarchy, and implementing a view at every stop. You're bordering on having a view for each DOM element, which is nonsense.

Let the template system do it's thing, and let the DOM events bubble up to your handlers. No need for views to be hyper-focused on one tiny section of the DOM. I get that it's good to have a strong division of responsibilities. It's also bad to have too many moving parts — no matter what you're building. This includes Backbone views.

So if you're keeping your single page application down to a sane handful of views, and things start to get complicated, stop. Don't make a diced-view soup. Take a walk, grab a coffee, and simplify your application. If your application has ten-thousand views — you're doing it wrong.

Backbone: Combining The where() and toJSON() Collection Methods

The two Backbone collection methods I use most often are probably where(), and toJSON(). However, they're difficult to use together sometimes. For example, I can filter my collection before I actually do anything with it using where(), but this gives me back an array of models. I can't do further Lodash processing on this array, because it has full-fledged models, not objects in it. I can't pass this array to my template context because, again, it's looking for plain objects, and not Backbone model instances.

Storing Backbone Views In Element Data

The data() jQuery function let's us store arbitrary data in an element. It doesn't actually store it in the DOM, but it's an elegant means to associate arbitrary application data with an element. It removes unnecessary code and complexity — let jQuery handle it. I often find myself having to create structures in my code that look similar to what I have in the DOM, essentially duplicating it. There's often no need for this, because if it's data that's specifically related to an element, that's what data() is for.

Parsing Dates in Backbone Models

The parse() method on Backbone.Model is useful for parsing out using model properties. These are typically things like dates — the API doesn't return a JavaScript Date instance — it's either a number or a string representation of a date. That said, it's not terribly useful to store these strings or numbers in date properties of models. For example, using parse(), you can add a level of certainty in your application that the date fields on your models will always be Date instances, and not numbers or strings.

Fetching Backbone Models The Safe Way

If you're using Backbone, odds are that you have several detail views for various types of objects. Before those views are rendered, you need to ensure that model has been fetched. Otherwise, you don't have anything to render, besides the template, perhaps with placeholders filling in for the real model data. Or maybe your application has already performed a fetch on the collection, in which case, we have all the data required to render the detail view of the model. But, unless you're keeping that collection synchronized, you could be rendering stale data.

Backbone Collection Fetch Scheduler

It's tricky to properly manage the the fetching of several Backbone collections in a given application. There are factors at play that require close attention. We don't want to put too much load on the server. We don't want to put too much load on the client. We need to consider things such as concurrency, and the ability to prioritize based on collection freshness. This seems like a lot to take on, and it maybe overkill to worry about such matters in smaller applications. But as the sheer volume of collections grows, as the complexity between the collection relationships increases, you're going to need some sort of fetch scheduling strategy.

Scalable Routing With Backbone

The typical Backbone application, at least the demo applications you'll find, use a single router instance to manage URLs. That's fine because where there are only a handful of possible URLs the application understands, creating more than one router instance is overkill. What I find strange, however, are the lack of examples that use multiple routers. Backbone exposes the router as a component to be extended and instantiated. It's by no means a singleton.

jQuery UI Widgets and Backbone Views

If you're like me and love the Backbone way of doing JavaScript development, it's hard to switch modes of thought when switching to other frameworks. For example, I also like the jQuery UI way of doing things. I'm used to thinking in terms of granular widgets, and not necessarily views. But a widget can be a view, right? All we have to do is make the widget perform the same task that a view normally would, just present the data to the user, respond to user events, and respond to data events. Is it possible?