Strengthening your Backbone

Related tags

Frameworks thorax


This repository has been archived and is not supported.

No Maintenance Intended


This projected was owned and maintained by Walmart. This project has reached its end of life and Walmart no longer supports this project.

We will no longer be monitoring the issues for this project or reviewing pull requests. You are free to continue using this project under the license terms or forks of this project at your own risk. This project is no longer subject to Walmart's bug bounty program or other security monitoring.

Actions you can take

We recommend you take the following action:

  • Review any configuration files used for build automation and make appropriate updates to remove or replace this project
  • Notify other members of your team and/or organization of this change
  • Notify your security team to help you evaluate alternative options

Forking and transition of ownership

For security reasons, Walmart does not transfer the ownership of our primary repos on Github or other platforms to other individuals/organizations. Further, we do not transfer ownership of packages for public package management systems.

If you would like to fork this package and continue development, you should choose a new name for the project and create your own packages, build automation, etc.

Please review the licensing terms of this project, which continue to be in effect even after decommission.


Selenium Test Status

An opinionated, battle tested Backbone + Handlebars framework to build large scale web applications.

Quick Start


Hello World

Thorax is used to build some of the biggest Backbone applications in the world but it's easy to get started.

var view = new Thorax.View({
  greeting: "Hello",
  template: Handlebars.compile("{{greeting}} world!")

Easy Data Binding

By default every property of your view is automatically available in the template. If a model is bound its attributes will also be made available.

var view = new Thorax.View({
  greeting: 'Hello',
  model: new Thorax.Model({
    location: 'world!'
  template: ...

Then in your template:

{{greeting}} {{location}}

Context Control

Don't like every property in your view being available in your template, or need to modify some model attributes? Just specify a context method to control what your template sees:

var view = new Thorax.View({
  model: new Thorax.Model({
    greeting: 'hello'
  context: function() {
    return {
      greeting: this.model.get('greeting').toUpperCase()
  template: ...

Then in your template:


Collection Rendering

Easily render collections with the collection helper. Thorax will make sure that your view stays current as models in your collection are added, removed or updated.

var view = new Thorax.View({
  collection: new Thorax.Collection([{
    title: 'Finish screencast',
    done: true
  template: ...

Then in your template:

{{#collection tag="ul"}}
    <input type="checkbox" {{#done}}checked{{/done}}
  <li>No todos yet.</li>

jQuery and Zepto Integration

Thorax extends the jQuery or Zepto $ object to allow you to get a reference to the nearest bound model, collection, or view.

var view = new Thorax.View({
  events: {
    'change input[type=checkbox]': function(event) {
      var model = $(;

Event Enhancements

Thorax extends the events hash to let you listen to view events in addition to DOM events, and let's you pass a hash of model or collection events to listenTo when a model or collection is bound to your view.

var view = new Thorax.View({
  events: {
    rendered: function() {}
    model: {
      change: function() {}
  model: new Thorax.Model()

Thorax also adds inheritable events to view classes, just call on on any class to listen for a DOM, view, model or collection event on any view.

Thorax.View.on('eventName', handler);

Form Handling

Easily capture entered form data with the serialize method which also provides event hooks for form validation. Models bound to the view will also automatically populate your forms.

var view = new Thorax.View({
  events: {
    'submit form': function(event) {
      var attrs = this.serialize();
  collection: new Thorax.Collection()

Embeddable Views

Easily embed one view within another with the view helper.

var view = new Thorax.View({
  child: new Thorax.View(...),
  template: ...

Then in your template:

{{view child}}

Layouts and Lifecycle

Thorax.LayoutView provides a container to place your views, and triggers lifecycle events on views placed within them. Layouts can be embedded in other views as well.

var layout = new Thorax.LayoutView();
var view = new Thorax.View({
  events: {
    ready: function() {},
    destroyed: function() {}

Server Side Rendering

Thorax allows for rendering outside of the normal browser context using environments such as Fruit Loops or PhantomJS to render content in the initial server response and then restore the view hierarchy on the client render. Rendering in such a manner allows for Thorax applications to expose their content for SEO purposes as well as speed up the perceived initial page load.

The restore process is well suited for handling distinctions between user and public data, allowing for the server response to include only public, long cache-able, content. The client can then augment this data with any user specific data on restoration.

Getting Started


Thorax Yeoman Generator

Using the Thorax Generator, you can generate a Todos example application. You can also generate a blank application and build it out to match the Todos example app. This is a great way to learn by doing.

Thorax in Backbone Fundamentals

Read an overview of the features of Thorax, as well as some of the theory behind some of the implementation details.

Route Based Module Loading

Backbone Fundamentals also covers Lumbar's approach to modular application development and routing, which is used in all of the seed projects except the standalone and Rails seeds.

Thorax Seed

Thorax seed provides an example of a Lumber and Server-Side JavaScript project in action. This commit shows an example of converting an existing Thorax+Lumbar application to support SSJS.


See the TodoMVC Thorax implementation and its source code. There is also a Lumbar flavored version of the implementation.

kenwheeler has an example Parse-Todos implementation of Thorax combined with Parse.



Thorax Yeoman Generator

The Thorax Generator will ask you questions before generating a new blank or predefined base project. This is the recommended way to get started.

The Thorax Generator also provides it's own extensive documentation and aims to help you understand how to setup a full stack Thorax application, including a minimal node express server and deployment instructions.

Bower component

Thorax is available as a Bower component. Just run bower install thorax in your project.

Thorax is tested against these dependencies (you can paste this in your bower.json:

"dependencies": {
  "jquery": "1.9.0",
  "underscore": "1.4.4",
  "zepto": "1.0.0",
  "handlebars": "1.0.0",
  "backbone": "1.0.0"

Note that either jQuery or Zepto is required, but not both.


Thorax is available on cdnjs, each build includes jQuery 1.9.0 (or Zepto 1.0.0rc1 on mobile), Backbone 0.9.9, Underscore 1.4.2 and Handlebars 1.0.0rc6.


When combined with CoffeeScript small Thorax apps can be written in a single file. This is ideal for creating small test apps within JSFiddle. Thorax can be selected as a framework (near the bottom of the list) in any fiddle, or you can try out any of the fiddles below:

API Reference


Thorax creates a special hash for each type of class to store all subclasses in your application. The use of Thorax.Views and Handlebars.templates (usually defined by Handlebars) is required to allow the view, template and other helper methods to operate, but the use of Thorax.Models and Thorax.Collections are optional and provided for consistency.

Class Registry
Thorax.View Thorax.Views
Thorax.Model Thorax.Models
Thorax.Collection Thorax.Collections
templates Handlebars.templates


If a name property is passed to any Thorax classes' extend method the resulting class will be automatically set in the corresponding registry.

//set class
  name: "my-view"

//get class

templates Handlebars.templates

A hash of templates, used by various Thorax helpers. If using the Lumbar or Rails boilerplate projects or the Thorax Generator this hash will be automatically generated from the files in your templates directories. To manually add a template to the hash:

Handlebars.templates['my-template-name'] = Handlebars.compile('template string');

If a View has the same name as a template in the templates hash, its `template' property will be automatically assigned.


Thorax.View provides additive functionality over Backbone.View but breaks compatibility in one important way in that it does not use an options object. All properties passed to the constructor become available on the instance:

var view = new Thorax.View({
  key: "value"
view.key === "value"

By default all instance properties are available in the template context. So when setting a key on the view it will by default be available in the template.

template view.template

Assign a template to a view. This may be a string or a function which receives a single context argument and returns a string. If the view has a name and a template of the same name is available the template will be auto-assigned.

new Thorax.View({
  template: Handlebars.compile("{{key}}")

render view.render([content])

Renders the view's template updating the view's el with the result, triggering the rendered event.


render can also accept a content argument that may be an element, string or a template function:

view.render('custom html');

restore view.restore(element, forceRerender)

Attempts to restore a given view with the passed element. Should this fail the view will be rerendered automatically. Rerendering may be forced by setting the forceRerender parameter to truthy. See Server Rendering for further discussion.

context view.context()

Used by render to determine what attributes are available in the view's template. The default context function returns this + this.model.attributes if a model is present on the view. The context method may be overridden to provide a custom context:

new Thorax.View({
  template: Handlebars.compile('{{key}}'),
  context: function() {
    return _.defaults(this.model.attributes, {
      key: 'value'

appendTo view.appendTo(element)

Appends the view to a given element which may be a CSS selector or DOM element. ensureRendered will be called and a ready event will be triggered. This is the preferred way to append your outer most view onto a page.

renderTemplate view.renderTemplate(name [,context])

Renders a given template with the view's context or the given context argument.

ensureRendered view.ensureRendered()

Ensure that the view has been rendered at least once.

conditionalRender view.conditionalRender([flag])

Renders the view if and only if shouldRender(flag) is true. Useful for ensuring that updates occur while still deferring final rendering until the view has been inserted into the DOM.

When flag is undefined this is effectively the opposite behavior of ensureRendered.

shouldRender view.shouldRender([flag])

Returns true if the view should be rendered based on flag and the current rendered state.

flag may be:

  • true : Always render
  • false : Never render
  • undefined : Render only if the view has been rendered previously

html view.html([content])

Get or set the innerHTML of the view, without triggering the rendered event.

_addChild view.addChild(child)

Register a view as being a child of the parent. This will release the child view when the parent is released.

this.childView = this._addChild(new ChildView);

If you are embedding a child view with the view helper this is automatically done for you. Use this when there are cases where the child would not be embedded, either due to the parent not rendering or the view helper being inside of a conditional.

children view.children

A hash of child view's indexed by cid. Child views may become attached to the parent with the view helper or may be automatically attached HelperView instances created by helpers created with registerViewHelper (such as the collection and empty helpers).

parent view.parent

If a view was embedded inside another with the view helper, or a generated HelperView (for instance the collection or empty helpers) it will have a parent view attribute. In the case of HelperViews, the parent will be the view that declared the helper in its template.

retain view.retain([owner])

Prevents a view from being destroyed if it would otherwise be. If a parent is destroyed all its children will be destroyed, or if it was previously passed to setView

Given the code below:


b will be destroyed, and a will not be.

When the optional owner parameter is passed, the retain reference count will automatically be reduced when the owner view is destroyed.

Views that have been retained must be released via release or they will leak.

This is done automatically for views that are connected to an existing element via the el attribute.

release view.release()

Release a view that was previously retained. If release is called and the view has a reference count of zero it will be destroyed, which will release all children, remove all events, unbind all models and collections, call remove and trigger the destroyed event.

release is usually called automatically if a view was attached to a LayoutView with the setView method, and another view is then passed to setView.

Generally this method is not needed unless you are retaining views.

setModel view.setModel(model [,options])

Setting model in the constructor will automatically call setModel, so the following are equivalent:

var view = new Thorax.View({
  model: myModel
// identical functionality as above

Sets the model attribute of a view then attempts to fetch the model if it has not yet been populated. Once set the default context implementation will merge the model's attributes into the context, so any model attributes will automatically become available in a template. In addition any events declared via view.on({model: events}) will be bound to the model with listenTo.

Accepts any of the following options:

  • fetch - Boolean, whether to fetch the model when it is set, defaults to true.
  • success - Callback on fetch success, defaults to noop
  • render - Render on the view on model:change? Defaults to undefined
    • true : Always render on change
    • false : Never render on change
    • undefined : Rerender if we have already been rendered
  • populate - Call populate with the model's attributes when it is set? Defaults to true.
    • Pass populate: {children: false} to prevent child views from having their inputs populated.
    • Pass populate: {context: true} to populate using the view's context rather than directly populating from the model's attributes.
  • errors - When the model triggers an error event, trigger the event on the view? Defaults to true

setCollection view.setCollection(collection [,options])

Setting collection in the constructor will automatically call setCollection, so the following are equivalent:

var view = new Thorax.View({
  collection: myCollection
// identical functionality as above

Sets the collection attribute of a view then attempts to fetch the collection if it has not yet been populated. In addition any events declared via view.on({collection: events}) will be bound to the collection with listenTo.

Accepts any of the following options:

  • render - Whether to render the collection if it is populated, or render it after it has been loaded. Defaults to undefined
    • true : Always render on change
    • false : Never render on change
    • undefined : Rerender if we have already been rendered
  • fetch - Whether or not to try to call fetch on the collection if shouldFetch returns true
  • success - Callback on fetch success, defaults to noop
  • errors - Whether or not to trigger an error event on the view when an error event is triggered on the collection
  • change - Whether or not to call updateItem when a model's change event fires. Defaults to true.

Note that while any view may bind a collection only a CollectionView will actually render a collection. A regular Thorax.View may declare a collection helper which in turn will generate and embed a CollectionView.

serialize view.serialize([event], callback [,options])

Serializes a form. callback will receive the attributes from the form, followed by a release method which must be called before the form can be submitted again. callback will only be called if validateInput returns nothing or an empty array. options may contain:

  • set - defaults to true, whether or not to set the attributes if valid on a model if one was set with setModel
  • validate - defaults to true, whether or not to call validateInput during serialization
  • children - defaults to true, whether or not to serialize inputs in child views
  • silent - defaults to true, whether or not to pass silent: true to model.set

Each form input in your application should contain a corresponding label. Since you may want to re-use the same form multiple times in the same view a @cid attribute with a unique value is provided to each render call of each template:

<label for="{{@cid}}-last-name"/>
<input name="last-name" id="{{@cid}}-last-name" value="Beastridge"/>
<label for="{{@cid}}-address[street]"/>
<input name="address[street]" value="123 Chestnut" id="{{@cid}}-address[street]"/>

new Thorax.View({
  events: {
    "submit form": function(event) {
      this.serialize(event, function(attributes, release) {
        attributes["last-name"] === "Beastridge";
        attributes.address.street === "123 Chestnut";
        //form is locked to prevent duplicate submission
        //until release is called

serialize Triggers the following events:

  • serialize - called before validation with serialized attributes
  • validate - with an attributes hash and errors array after validateInput is called
  • invalid - with an errors array, if validateInput returned an array with any errors
  • root - the root element to serialize within, defaults to this.$el

If your view uses inputs with non standard names (or no names, multiple inputs with the same name, etc), use the serialize event:

this.on('serialize', _.bind(function(attributes) {
  attributes.custom = this.$('.my-input').val();
}, this));

populate view.populate([attributes] [,options])

Populate the form fields in the view with the given attributes. The keys of the attributes should correspond to the names of the inputs. populate is automatically called with the response from view.context() when setModel is called. By default this is just model.attributes.

  "last-name": "Beastridge"
  address: {
    street: "123 Chestnut"

populate triggers a populate event. If your view uses inputs with non standard names (or no names, multiple inputs with the same name, etc), use this event:

this.on('populate', _.bind(function(attributes) {
}, this));

To prevent child views from having their inputs populated use:

view.populate(object, {
  children: false

validateInput view.validateInput(attributes)

Validate the attributes created by serialize, must return an array or nothing (if valid). It's recommended that the array contain hashes with name and message attributes, but arbitrary data or objects may be passed. If the array has a zero length the attributes are considered to be valid. Returning an array with any errors will trigger the invalid event.

validateInput: function(attributes) {
  var errors = [];
  if (attributes.password && !attributes.password.match(/.{6,11}/)) {
    errors.push({name: 'password', message: 'Invalid Password'});
  return errors;


registerViewHelper Handlebars.registerViewHelper(name [,viewClass] ,callback)

Note that this differs from Handlebars.registerHelper. Registers a helper that will create and append a new HelperView instance, with its template attribute set to the value of the captured block. callback will receive any arguments passed to the helper followed by a HelperView instance. Named arguments to the helper will be present on options attribute of the HelperView instance.

A HelperView instance differs from a regular view instance in that it has a parent attribute which is always set to the declaring view, and a context which always returns the value of the parent's context method. The collection, empty and other built in block view helpers are created with registerViewHelper.

A helper that re-rendered a HelperView every time an event was triggered on the declaring view could be implemented as:

Handlebars.registerViewHelper('on', function(eventName, helperView) {
  helperView.listenTo(helperView.parent, eventName, function() {

An example use of this would be to have a counter that would increment each time a button was clicked. In Handlebars:

{{#on "incremented"}}{{i}}{/on}}
{{#button trigger="incremented"}}Add{{/button}}

And the corresponding view class:

new Thorax.View({
  events: {
    incremented: function() {
  initialize: function() {
    this.i = 0;
  template: ...

In addition, if a view class is specified as the second argument to registerViewHelper, the helper will always initialize a view of that class instead of a HelperView:

  Thorax.CollectionHelperView, function(collection, view) {



A view to contain a single other view which will change over time, (multi-pane single page applications for instance), triggering a series of events . By default this class has no template. If one is specified use the layout-element helper to determine where setView will place a view. A Thorax.LayoutView is a subclass of Thorax.View and may be treated as a view in every regard (i.e. embed multiple LayoutView instances in a parent view with the view helper).

setView view.setView(view [,options])

Set the current view on the LayoutView, triggering activated, ready and deactivated events on the current and previous view during the lifecycle. ensureRendered is called on views passed to setView. By default destroy is called on the previous view when the new view is set.

To implement animations using setView pass a transition callback to setView which will receive the new view being set, the old view (if present), append, remove and complete functions which will execute the needed DOM and view operations.

layout.setView(newView, {
  transition: function(newView, oldView, append, remove, complete) {
    yourAnimation(function() {

getView view.getView()

Get the current view that was previously set with setView.


Enhances Backbone.Model with the concept of whether or not the model is populated and whether or not it should be automatically fetched. Note that when passing a model to view.setModel it must be an instance of Thorax.Model and not Backbone.Model.

isEmpty model.isEmpty()

Used by the empty helper. In a collection the implementations of isEmpty and isPopulated differ, but in a model isEmpty is an alias for !isPopulated.

isPopulated model.isPopulated()

Used by setModel to determine whether or not to fetch the model. The default implementation checks to see if any keys that are not id and are not default values have been set.


Enhances Backbone.Collection with the concept of whether or not the collection is populated and whether or not it should be automatically fetched. Note that when passing a collection to view.setCollection it must be an instance of Thorax.Collection and not Backbone.Collection.

isEmpty collection.isEmpty()

Used by the empty helper and the emptyTemplate and emptyItem options of a CollectionView to check whether a collection is empty. A collection is only treated as empty if it isPopulated and zero length.

isPopulated collection.isPopulated()

Used by setCollection to determine whether or not to fetch the collection.


A class that renders an itemTemplate or itemView for each item in a collection passed to it in its constructor, or via setCollection. The view will automatically update when items are added, removed or changed.

The collection helper will automatically create and embed a CollectionView instance for you. If programmatic access to the view's methods are needed (for instance calling appendItem or specifying an itemFilter) it's best to create a CollectionView directly and embed it with the view helper as you would any other view.

itemTemplate view.itemTemplate

A template name or template function to use when rendering each model. If using the collection helper the passed block will become the itemTemplate. Defaults to + '-item'

itemView view.itemView

A view class to be initialized for each item. Can be used in conjunction with itemTemplate.

itemContext view.itemContext(model, index)

A function in the declaring view to specify the context for an itemTemplate, receives model and index as arguments. itemContext will not be used if an itemView is specified as the itemView's own context method will instead be used.

A collection helper may specify a specific function to use as the itemContext if there are multiple collections in a view:

{{#collection todos item-context="todosItemContext"}}

itemFilter view.itemFilter(model, index)

A method, which if present will filter what items are rendered in a collection. Receives model and index and must return boolean. The filter will be applied when models' fire a change event, or models are added and removed from the collection. To force a collection to re-filter, call updateFilter on the view or collection view.

Items are hidden and shown with $.hide and $.show rather than being removed or appended. In performance critical views with large collections consider filtering the collection before it is passed to the view or on the server.

A collection helper may specify a specific function to use as the itemFilter if there are multiple collections in a view:

{{#collection todos item-filter="todosItemFilter"}}

updateFilter view.updateFilter()

If using itemFilter, call this method to force the collection view to re-filter.

emptyTemplate view.emptyTemplate

A template name or template function to display when the collection is empty. If used in a collection helper the inverse block will become the emptyTemplate. Defaults to + '-empty'

emptyView view.emptyView

A view class to create an instance of when the collection is empty. Can be used in conjunction with emptyTemplate.

loadingTemplate view.loadingTemplate

A template name or template function to display when the collection is loading.

loadingView view.loadingView

A view class to create an instance of when the collection is loading. Can be used in conjunction with loadingTemplate.

loadingPlacement view.loadingPlacement()

An index to place the loadingView or loadingTemplate at. Defaults to this.collection.length.

appendItem view.appendItem(modelOrView [,index] [,options])

Append a model (which will used to generate a new itemView or render an itemTemplate) or a view at a given index in the CollectionView. If passing a view as the first argument index may be a model which will be used to look up the index.

By default this will trigger a rendered:item event, silent: true may be passed in the options hash to prevent this. To also prevent the appended item from being filtered if an itemFilter is present pass filter: false in the options hash.

removeItem view.removeItem(model)

Remove an item from the view.

updateItem view.updateItem(model)

Equivalent to calling removeItem then appendItem. Note that this is mainly meant to cover edge cases, by default changing a model will update the needed item (whether using itemTemplate or itemView).


tag Thorax.Util.tag(name, htmlAttributes [,content] [,context])

Generate an HTML string. All built in HTML generation uses this method. If context is passed any Handlebars references inside of the htmlAttributes values will rendered with the context.

Thorax.Util.tag("div", {
  id: "div-{{number}}"
}, "content of the div", {
  number: 3


The ServerMarshal provides a mechanism for sharing data between server rendered content and the views that restore upon the HTML on the client.

When dealing with simple primitives that may be serialized via JSON the values are stored directly in the server marshal store JSON object. For more complex objects such as models, collections, and views, a path relative to the handlebars rendering context is saved as a reference that can be resolved against the client-side equivalents.

store$el, name, data, dataIds, options)

Associates the given data with $el in the server marshal data store. May be restored on the client side via the Thorax.ServerMarshal.load API.

  • $el the $ instance associated with the given element
  • name the name of the data point to be saved
  • data data to be stored. May be an array, object, or primitive value. Complex values must contain only primitive values or have proper associated dataIds element to allow for lookup on the client side.
  • dataIds context paths associated with the data defined in data, if available.
  • options options object. This object generally mirrors the options object passed to handlebars helpers, which may be passed directly. Fields may include:
    • data current handlebars data object
      • contextPath current context path for execution scope
      • root current handlebars root rendering context
      • view current view being rendered

Data storage rules:

  • Numbers, Strings, Booleans, Nulls, and Objects with a toJSON implementation as all stringified
  • When dataIds is a string value, the context path is stored for the data field
  • When paired with a matching dataId structure, Arrays and objects are evaluated to one level deep.
    • Primitive values fitting above are stringified
    • All other objects are store the context path by combining and dataIds[key]
  • Otherwise a server-marshal-object error is thrown

The contextPath value is a data field tracked within Handlebars helpers. This is is the "path" from the root of the context that a particular handlebars lookup resolves to and is used to lookup the helper parameters at restore time. As a general rule if you are calling fn or inverse with a different context than you were called with then you will likely need to update the contextPath value. The appendContextPath helper is available for simple path updates:

  data.contextPath = Handlebars.Utils.appendContextPath(data.contextPath, 'foo');

load Thorax.ServerMarshal.load(el, name, parentView, context)

Returns the named server data for a given element.

  • el element to load data for
  • name data item name
  • parentView the view instance that contains this particular element
  • context the rendering context

For complex objects, parentView and context will be used to lookup any context path objects saved from the server side. context values take priority over parentView values to match the behavior of the rendering pipeline.

serialize Thorax.ServerMarshal.serialize()

Retrieves the stringified representation of the marshal data set. Generally this does not need to be called explicitly as an onEmit handler will ensure that the data is output for the client exec.

destory Thorax.ServerMarshal.destroy($el)

Removes any marshal data that may be associated with a given element.


$.view $([options])

Get a reference to the nearest parent view. Pass helper: false to options to exclude HelperViews from the lookup. Useful when registering DOM event handlers:


$.model $([view])

Get a reference to the nearest bound model. Can be used with any $ object but most useful in event handlers.


A view may be optionally passed to limit the lookup to a specific view.

$.collection $([view])

Get a reference to the nearest bound collection. Can be used with any $ object but most useful in event handlers.


A view may be optionally passed to limit the lookup to a specific view.

Event Enhancements

Thorax adds inheritable class events for all Thorax classes and significant enhancements to the Thorax.View event handling.

Inheritable Events ViewClass.on(eventName, callback)

All Thorax classes have an on method to observe events on all instances of the class. Subclasses inherit their parents' event handlers. Accepts any arguments that can be passed to viewInstance.on or declared in the events hash.

  'click a': function(event) {


Model Events

When a model is bound to a view with setModel (automatically called by passing a model option in the constructor) any events on the model can be observed by the view in this way. For instance to observe any model change event when it is bound to any view:

  model: {
    change: function() {
      // "this" will refer to the view

Collection Events

When a collection is bound to a view with setCollection (automatically called by passing a collection option in the constructor) any events on the collection can be observed by the view in this way. For instance to observe any collection reset event when it is bound to any view:

  collection: {
    reset: function() {
      // "this" will refer to the view

View Events

The events hash has been enhanced to allow view events to be registered along side DOM events:

  events: {
    'click a': function(event) {},
    rendered: function() {}

DOM Events view.on(eventNameAndSelector, callback [,context])

The on method will now accept event strings in the same format as the events hash, for instance click a. Events separated by a space will still be treated as registering multiple events so long as the event name does not start with a DOM event name (click, change, mousedown etc).

DOM events observed in this way will only operate on the view itself. If the view embeds other views with the view helper that would match the event name and selector, they will be ignored. For instance declaring:

view.on('click a', function(event) {})

Will only listen for clicks on a elements within the view. If the view has children that has a elements, this handler will not observe clicks on them.

DOM events may be prefixed with the special keyword nested which will apply the event to all elements in child views:

view.on('nested click a', function() {})

Thorax will add an attribute to the event named originalContext that will be the Element object that would have been set as this had the handler been registered with jQuery / Zepto:

$('a').on('click', function() {});
view.on('click a', function(event) {
  // event.originalContext === what "this" would be in the
  // first handler

When doing a server render, all DOM event handlers are silently discarded, as the majority do not make sense and environments such as Fruit Loops do not support. Code that relies on DOM events such as submit will need to take this into account.

_addEvent view._addEvent(eventParams)

This method is never called directly, but can be specified to override the behavior of the events hash or any event arguments passed to on. For each event declared in either manner _addEvent will be called with a hash containing:

  • type "view" || "DOM"
  • name (DOM events will begin with ".delegateEvents")
  • originalName
  • selector (DOM events only)
  • handler

All of the behavior described in this section is implemented via this method, so if overriding make sure to call Thorax.View.prototype._addEvent in your child view.

Data Loading


Thorax wraps fetch (and therefore load) on models and collections with a queuing mechanism to ensure that multiple sync calls for the same url will not trigger multiple HTTP requests. To force a fetch or load call to create a new HTTP request regardless of whether an identical request is in the queue use the resetQueue option:

  resetQueue: true
  success: function() {}

bindToRoute Thorax.Util.bindToRoute(callback [,failback])

Used by model.load and collection.load. Binds the callback to the current route. If the browser navigtates to another route in the time between when the callback is bound and when it is executed, callback will not be called. Else failback will be called if present.

routerMethod: function() {
  var callback = Thorax.Util.bindToRoute(function() {
    //callback called if browser is still on route
  setTimeout(callback, 5000);

load modelOrCollection.load(callback [,failback] [,options])

Calls fetch on the model or collection ensuring the callbacks will only be called if the route does not change. callback and failback will be used as arguments to bindToRoute. options will be passed to the fetch call on the model or collection if present.

routerMethod: function(id) {
  var view = new Thorax.View();
  var model = new Application.Model({id: id});
  model.load(function() {
    //callback only called if browser still on this route
  }, function() {
    //failback only called if browser has left this route

Triggers load:start and load:end events on the model or collection, and additionally on a view if it has bound the object via setModel or setCollection.

By default the events will propagate to a root object set with setRootObject. Pass background: true as an option to prevent the event from being triggered on the rootObject.

setRootObject Thorax.setRootObject(obj)

Set the root object that will receive load:start and load:end events if the load:start was not a background event. This is useful to implement a global loading indicator.

loadHandler Thorax.loadHandler(startCallback, endCallback)

Generates an load:start event handler that when triggered will then monitor the associated object for a load:end event. If the duration between the start and the end events exceed _loadingTimeoutDuration then the start and end callbacks will be triggered at the appropriate times to allow the display of a loading UI.

view.on("load:start", Thorax.loadHandler(
  function(message, background, object) {
  function(background, object) {

_loadingClassName view._loadingClassName

Class name to add and remove from a view's el when it is loading. Defaults to loading.

_loadingTimeoutDuration view._loadingTimeoutDuration

Timeout duration in seconds before a load:start callback will be triggered. Defaults to 0.33 seconds. If for instance the load:end event was triggered 0.32 seconds after the load:start event the load:start callback would not be called.

_loadingTimeoutEndDuration view._loadingTimeoutEndDuration

Just like _loadingTimeoutDuration but applies to load:end. Defaults to 0.10 seconds.

Template Helpers

template {{template name [options]}}

Embed a template inside of another, as a string. An associated view (if any) will not be initialized. By default the template will be called with the current context but extra options may be passed which will be added to the context.

{{template "path/to/template" key="value"}}

If a block is used, the template will have a variable named @yield available that will contain the contents of the block.

{{#template "child"}}
  content in the block will be available in a variable
  named "@yield" inside the template "child"

This is useful when a child template will be called from multiple different parents.

super {{super}}

Embed the template from the parent view within the child template.


view {{view name [options]}}

Embed one view in another. The first argument may be the name of a new view to initialize or a reference to a view that has already been initialized.

{{view "path/to/view" key="value"}}
{{view viewInstance}}

If a block is specified it will be assigned as the template to the view instance:

{{#view viewInstance}}
  viewInstance will have this block
  set as its template property

element {{element name [options]}}

Embed a DOM element in the view. This uses a placeholder technique to work, if the placeholder must be of a certain type in order to be valid (for instance a tbody inside of a table) specify a tag option.

{{element domElement tag="tbody"}}

button {{#button methodName [htmlAttributes...]}}

Creates a button tag that will call the specified methodName on the view when clicked. Arbitrary HTML attributes can also be specified.

{{#button "methodName" class="btn"}}Click Me{{/button}}

The tag name may also be specified:

{{#button "methodName" tag="a" class="btn"}}A Link{{/button}}

A trigger attribute will trigger an event on the declaring view:

{{#button trigger="eventName"}}Button{{/button}}

A button can have both a trigger attribute and a method to call:

{{#button "methodName" trigger="eventName"}}Button{{/button}}

The method may also be specified as a method attribute:

{{#button method="methodName"}}Button{{/button}}

url {{url urlString expand-tokens=bool}}

Prepends "#" if Backbone.history.pushSate is disabled or prepends Backbone.history.root if it is enabled. If expand-tokens=true is passed, then any handlebars tokens will be resolved with the current context. For example if the context had an id attribute {{id}} would be replaced with the value of id:

{{url "articles/{{id}}" expand-tokens=true}}

Multiple arguments can be passed and will be joined with a "/":

{{url "articles" id}}

link {{#link url [htmlAttributes...]}}

Creates an a tag that will call Backbone.history.navigate() with the given url when clicked. Passes the url parameter to the url helper with the current context. Do not use this method for creating external links. Like the url helper, multiple arguments may be passed as well as an expand-tokens option.

{{#link "articles/{{id}}" expand-tokens=true class="article-link"}}Link Text{{/link}}

To call a method from an a tag use the button helper:

{{#button "methodName" tag="a"}}My Link{{/button}}

Like the button helper, a trigger attribute may be specified that will trigger an event on the declaring view in addition to navigating to the specified url:

{{#link "articles" id trigger="customEvent"}}Link Text{{/link}}

The href attribute is required but may also be specified as an attribute:

{{#link href="articles/{{id}}" expand-tokens=true}}Link Test{{/link}}

collection {{collection [collection] [options...]}}

Creates and embeds a CollectionView instance, updating when items are added, removed or changed in the collection. If a block is passed it will be used as the item-template, which will be called with a context of the model.attributes for each model in the collection.

{{#collection tag="ul"}}

Options may contain tag, class, id and the following attributes which will map to the generated CollectionView instance:

  • item-templateitemTemplate
  • item-viewitemView
  • empty-templateemptyTemplate
  • empty-viewemptyView
  • loading-templateloadingTemplate
  • loading-viewloadingView
  • item-contextitemContext
  • item-filteritemFilter

Any of the options can be specified as variables in addition to strings:

{{collection item-view=itemViewClass}}

By default the collection helper will look for this.collection, but if your view contains multiple collections a collection argument may be passed:

{{collection myCollection}}

When rendering this.collection many properties will be forwarded from the view that is declaring the collection helper to the generated CollectionView instance:

  • itemTemplate
  • itemView
  • itemContext
  • itemFilter
  • emptyTemplate
  • emptyView
  • loadingTemplate
  • loadingView
  • loadingPlacement

As a result the following two views are equivalent:

// render with collection helper, collection
// properties are forwarded
var view = new Thorax.View({
  collection: new Thorax.Collection(),
  itemView: MyItemClass,
  itemContext: function(model, i) {
    return model.attributes;
  template: Handlebars.compile('{{collection}}')

// directly create collection view, no property
// forwarding will occur
var view = new Thorax.View({
  collectionView: new Thorax.CollectionView({
    collection: new Thorax.Collection(),
    itemView: MyItemClass
    itemContext: function(model, i) {
      return model.attributes;
  template: Handlebars.compile('{{view collectionView}}')

empty {{#empty [modelOrCollection]}}

A conditional helper much like if that calls isEmpty on the specified object. In addition it will bind events to re-render the view should the object's state change from empty to not empty, or vice versa.

{{#empty collection}}
  So empty!

To embed a row within a collection helper if it the collection is empty, specify an empty-view or empty-template. Or use the else block of the collection helper:

{{#collection tag="ul"}}
  <li>Some very fine data</li>
  <li>So very empty</li>

collection-element {{collection-element [htmlAttributes...]}}

By default Thorax.CollectionView instances have no template. Items will be appended to and removed from the view's el. Alternatively a template can be specified and collection-element used to specify where the individual items in a collection will be rendered.

  {{collection-element tag="ul" class="my-list"}}

layout-element {{layout-element [htmlAttributes...]}}

By default Thorax.LayoutView instances have no template, setView will append directly to the view's el. Alternatively a template can be specified and a layout-element and setView will append to that element.

  {{layout-element tag="li" id="my-layout"}}

loading {{#loading}}

A block helper to use when the view is loading. For collection specific loading the CollectionView accepts loadingView and loadingTemplate options to append an item in a collection when it is loading.

  View is loading a model or collection.
  View is not loading a model or collection.

Catalog of Built-in Events

rendered rendered ()

Triggered on a view when the rendered method is called.

child child (instance)

Triggered on a view every time a child view is appended into the view with the view helper.

ready ready (options)

Triggered when a view is appended to the DOM with appendTo or when a view is appended to a LayoutView via setView. Setting focus and other behaviors that depend on the view being present in the DOM should be handled in this event.

This event propagates to all children, including children that will be bound after the view is created. options will contain a target view, which is the view that triggered the event.

activated activated (options)

Triggered on a view immediately after it was passed to a LayoutView's setView method. Like ready this event propagates to children and the options hash will contain a target view.

deactivated deactivated (options)

Triggered on a view when it was previously passed to the setView method on a LayoutView, and then another view is passed to setView. Triggered when the current view's el is still attached to the parent. Like ready this event propagates to children and the options hash will contain a target view.

destroyed destroyed ()

Triggered on a view when the release method is called and the reference count is zero. Useful for implementing custom view cleanup behaviors. release will be also be called if it was previously passed to the setView method on a LayoutView, and then another view is passed to setView.

change:view:start change:view:start (newView [,oldView] ,options)

Trigged on a Thorax.LayoutView immediately after setView is called.

change:view:end change:view:end (newView [,oldView] ,options)

Trigged on a Thorax.LayoutView after setView is called, the old view has been destroyed (if present) and the new view has been attached to the DOM and had its ready event triggered.

helper helper (name [,args...] ,helperView)

Triggered on a view when a view helper (such as collection, empty, etc) create a new HelperView instance.

helper:name helper:name ([,args...] ,helperView)

Triggered on a view when a given view helper creates a new HelperView instance.

{{#collection cats}}{{/collection}}

view.on('helper:collection', function(collection, collectionView) {


serialize serialize (attributes)

Triggered on a view when serialize is called, before validateInput is called with the serialized attributes.

validate validate (attributes, errors)

Triggered on a view when serialize is called, passed an attributes hash and errors array after validateInput is called. Use in combination with the invalid event to display and clear errors from your views.

  validate: function(attributes, errors) {
    //clear previous errors if present
  invalid: function(errors) {
    errors.forEach(function(error) {
      //lookup input by
      //display error from error.message

invalid invalid (errors)

Triggered on a view when serialize is called, if validateInput returned an array with any errors.

populate populate (attributes)

Triggered on a view when populate is called. Passed a hash containing the attributes that the view will be populated with.

load:start load:start (message, background, target)

Triggered on a model or collection by fetch or load and on a view if it has bound the model or collection with setModel or setCollection. Always generate a handler for a load:start event with Thorax.loadHandler.

load:end load:end (target)

Triggered on a model or collection by fetch or load and on a view if it has bound the model or collection with setModel or setCollection. Never observe this directly, always use Thorax.loadHandler on load:start.

rendered:collection rendred:collection (collectionView, collection)

Triggered on a CollectionView or the view calling the collection helper every time render is called on the CollectionView.

rendered:item rendered:item (collectionView, collection, model, itemElement, index)

Triggered on a CollectionView or the view calling the collection helper every time an item is rendered in the CollectionView.

rendered:empty rendered:empty (collectionView, collection)

Triggered on a CollectionView or the view calling the collection helper every time the emptyView or emptyTemplate is rendered in the CollectionView.

restore restore(forceRerender)

Triggered when the view is being restored to the current element. Listeners should be aware that it's possible for a rerender to occur while the restore event has triggered and should be able to handle this case gracefully. after-restore may provide a better option for cases that need to apply DOM changes after any potential render operations. If the current restore process will force a rerender then the forceRerender parameter will be truthy.

after-restore after-restore()

Triggered when the view has been restored and possibly rerendered to the current element. If the current restore process will force a rerender then the forceRerender parameter will be truthy.

restore:collection restore:collection(collectionView, el)

Triggered on a CollectionView or a view calling the collection helper when the collection is restored.

restore:item restore:item(collectionView, el)

Triggered on a CollectionView or a view calling the collection helper upon restoring an individual item element in the collection.

restore:empty restore:empty(collectionView, el)

Triggered on a CollectionView or a view calling the collection helper when a restore operation includes an empty view or template.

restore:fail restore:fail(info)

Triggered when a particular view can not be restored. info may be a free form object but generally it will have a type field, outlined below, and a view field listing the view instance that failed.


  • previously-rendered: View has been rendered already
  • remaining: View has children that were not restored and must do a partial rerender
  • not-restorable: View was explicitly marked as not restorable
  • serialize: Unable to marshal one or more of the parameters passed to the helper
  • collection-remove: Item removed due to not being found in client-side collection
  • collection-missing: Item rendered due to not existing in server-side collection
  • collection-depthed-query: Attempted to use an inline collection item or empty template with ../ references.

HTML Attributes

Thorax and its view helpers generate a number of custom HTML attributes that may be useful in debugging or generating CSS selectors to be used as arguments to $ or to create CSS. The *-cid attributes are generally used only internally. See $.model, $.collection and $.view to get a reference to objects directly from the DOM. The *-name attributes will only be present if the given objects have a name property.

  <td>View elements rendered on the server side. `true` signifies that restoring is possible. `false` that it's explicitly disallowed.</td>
  <td>Helper View elements rendered on the server side. Provides the name of the helper view.</td>
  <td>Elements with `ServerMarshal` data associated with them.</td>
Attribute Name Attached To
`data-view-cid` Every view instances' `el`
`data-view-name` Same as above, only present on named views
`data-collection-cid` Element generated by the `collection helper`
`data-collection-name` Same as above, only present when the bound collection is named
`data-collection-empty` Set to "true" or "false" depending on whether the bound collection `isEmpty`
`data-collection-element` Set by the `collection-element`, determines where a collection in a `CollectionView` will be rendered.
`data-view-empty` Collection view's empty element
`data-model-cid` A view's `el` if a model was bound to the view or each item element inside of elements generated by the collection helper
`data-model-id` A view's `el` if a model was bound to the view or each item element inside of elements generated by the collection helper
`data-model-name` Same as above, only present if the model is named
`data-layout-cid` The element generated by the `layout` helper or `el` inside of a `LayoutView` or `ViewController` instance
`data-view-helper` Elements generated by various helpers including `collection` and `empty` from the collection plugin
`data-call-method` Elements generated by the `link` and `button` helpers
`data-trigger-event` Elements generated by the `link` and `button` helpers

When creating CSS selectors it's recommended to use the generated attributes (especially data-view-name) rather than assigning custom IDs or class names for the sole purpose of styling.

[data-view-name="my-view-name"] {
  border: 1px solid #ddd;

Error Handling

Certain critical code paths are executed using the bindSection and runSection APIs. Should code executed on these paths throw, additional information regarding the code location, etc may be logged and used for debugging.

Override these APIs with your own logging / debugging handler or utilize Costanza for an enhanced error tracking.

onException Thorax.onException(name, error, info)

Logs exceptions when they occur. Passed to the function are a unique identifier, name, the thrown exception, error, and an object containing any additional information, info. The default implementation is null instead of a function which makes Thorax not intervene with the exception process at all. The typical use case for this method is if you use an error reporting service, such as Costanza, or in this example, Raven.js:

Throax.onException = function(name, error) {

bindSection Thorax.bindSection(name, info, callback)

Wraps a callback in an error wrapper. Included with the callback is an identifying name value and any relevant information, info that may help debugging the exception.

By default this calls Thorax.onException if it has been defined and an exception is thrown. Implementors may override this method to provide additional error handling before exceptions occur.

runSection Thorax.runSection(name, info, callback)

Immediately executed version of bindSection. The default implementation delegates to bindSection.

Server Rendering

Server side rendering is designed around Fruit Loops, but may be performed in any environment that supports the $ API as well as a few core APIs used to control the page life cycle.

  • $serverSide Boolean flag set to true when rendering server side content.
  • FruitLoops.emit() Called when the page should be sent back to the client.
  • FruitLoops.onEmit(calback) Registers a callback which will be called just prior to the emit operation.

Restore Process

The restore process involves walking the DOM hierarchy looking for nodes that are annotated with the data-view-restore attribute. When such a node is found Thorax will attempt to restore based on a variety of steps discussed in the Restore Methods section below.

This process is kicked off by either an explicit call to View.restore or by calling LayoutView.setView on a previously restored layout view.

The application restore process might look something like:

var appEl = $('[data-view-name="application"]');
if (appEl.length) {
  // Restore the application view explicitly
} else {

Followed by normal controller execution, ultimately culminating in setView call, which will restore the rendered child.

Restore Methods

There is no definitive algorithm for restoring views, instead the following heuristics are used. In the event of a mismatch the restore:fail event will be emitted on the candidate view with additional debugging information regarding what portion of the heuristic failed.

General Rules

If the candidate view instance has already been rendered then the previous element will be replaced with the existing view element. This case is tracked by restore:fail with a type field of prev-render.

By default restore operations are depth first recursive. This allows for restore operations to partially rerender content for the minimal number of rerender operations.

Any view that is explicitly marked with data-view-restore=false will be rerendered on the client. This shortcircuits the tree traversal and causes all children to be rerendered as well.

setView calls

When setView is called an attempt will be made to restore the view to the layout view's child element if marked for restore. This assumes that the view is a named view. Should it not be a rerender will occur.

Helper Views

Elements rendered via a helper view such as view or collection will automatically be restored. This is done by saving the parameters passed to the helper view into the server marshal store. On restore the helper view will be executed in a similar manner to the initial execution, with the distinction that the restore method will be called after the view has initialized.

When using helper views the restore might be forced to rerender if utilizing helpers that do no properly set the contextPath or if passed a depthed parameter, i.e. {{view ../foo}} as these can not be safely resolved. This is tracked via the restore:fail event with type serialize and is determined on the server-side.

Additionally helpers that utilize subexpressions to resolve complex values are unable to be restored via path lookup and will force a rerender.

Collection Views

Collection views follow the same restore rules as helper views but add the ability to restore nested child views.

Rerender cases (additional to the helper cases):

  • Use of a block helper that has a ../ reference:
  • Use of collections that do not have an id value.

Note that overriding renderItem is allowed but discouraged as this has additional overhead vs. providing an itemView or itemTemplate value. This also applies to renderEmpty.

Best Practices

In general there are a number of things that help avoid rerender cases.


While in development mode tracking the number of times that a rerender case is triggered is vital for ensuring that the restore behavior is actually benefiting the site.

This might be as simple as a global logger on the restore:fail event:

View.on('restore:fail', function(info) {
  console.log('restore:fail', info);

Custom Restore Logic

It's recommended that views needing custom restore behavior do so by providing a restore event listener rather than overriding the restore method. This is due to the manner in which partial restores are implemented, delegating to the super class implementation may cause a rerender meaning any non-restored children are rerendered as well.

Should a view absolutely need to prevent the default restore behavior it can override the restore method but it must manually remove the data-view-restore attribute and also perform any child traversal necessary.

For most situations it should not be necessary to provide a custom restore implementation but cases that implement custom view insertion logic, i.e. calling DOM methods to insert the child view, will likely need to provide some level of custom restore logic. Ex:

  CustomView.on('restore', function() {
    var child = this.$('.child-view');
    if (child.length) {

Data Loading

Since pending fetch operations might rerender the content of a just restored view, it's recommended that the JSON content is cached in a manner that is accessible on the initial page load to avoid unnecessary rendering operations after restore. Fruit Loops offers such a system via the $serverCache local variable. Should this not be possible, the thorax rendering pipeline will handle any the restore and subsequent rerender properly.

Note that there are issues that might arise if a different model data source is used on the client vs. the server, a personalized vs public data source for example. When such data is loaded prior to the restore operation, it might be necessary to provide a custom restore step that checks if this data has changed and rerender as there is no clean way for Thorax to determine if a model's data has changed between the two states.

Error Codes


button helper must have a method name as the first argument or a 'trigger', or a 'method' attribute specified.


link helper requires an href as the first argument or an href attribute.


collection-element helper must be declared inside of a CollectionView


Cannot use super helper when parent has no name or template.


Hash arguments are not allowed in the view helper as templates should not introduce side effects to view instances.


layout-element helper must be used within a LayoutView.


Both set and reset were passed to fetch, must use one or the other.


render was called which triggered an event handler which in turn called render. Infinite recursion was halted.


Handlebars template compiled without data, use: Handlebars.compile(template, {data: true})


A helper view that has been destroyed was inserted into the view.


A void tag such as img was rendered with content in Thorax.Util.tag.


A complex object was serialized without a proper context path to lookup the object on the client side. See Thorax.ServerMarshal for more discussion on context paths.


$.view found a view element that was inserted manually into the DOM and was not registered with _addChild or retain. Call parent._addChild(view) or view.retain() on view insertion or instantiation.

  • `` keeps being undefined in likely race condition.

    `` keeps being undefined in likely race condition.

    Atlas CI has basically ground to a halt due to the following error in Thorax.

    Thorax has this code with a comment about a race condition:

    var loadingTimeout = self._loadingTimeoutDuration !== undefined ?
    self._loadingTimeoutDuration : Thorax.View.prototype._loadingTimeoutDuration;
    loadInfo.timeout = setTimeout(
      Thorax.bindSection('load-start', function() {
        // We have a slight race condtion in here where the end event may have occurred
        // but the end timeout has not executed. Rather than killing a cumulative timeout
        // immediately we'll protect from that case here
        if ( { // <= ERROR RIGHT HERE
 = true;
, loadInfo.message, loadInfo.background, loadInfo);
    loadingTimeout * 1000);

    This corresponds to for v2.3.2 from the built version.

    And then in tests we have loadInfo === undefined. Here's the closed thing we have yet in Atlas unit tests:

    1) app/cart/ views/ cart/ sign-in-modal "before each" hook:
    Uncaught TypeError: 'undefined' is not an object (evaluating '') (http://localhost:9876/js/lib/thorax/thorax.js:2699)

    Environments known to fail:

    • Linux + PhantomJS v1.9.7-3 (via grunt-mocha-phantomjs and grunt-blanket-mocha)
    • Mac OS X + PhantomJS v1.9.7-3 (via grunt-mocha-phantomjs and grunt-blanket-mocha)

    We'll look for deeper stack traces from here.

    Other Information:

    • Occurences / Frequency: We had sporadic (like once a week failures) for about a month now. As of two days ago it is now like every other build on Linux CI machine and ~1/25 tests on local MacBooks.
    • Determinism: Many different tests fail with the error. We haven't pinned any causation yet other than early tests in the 2000+ suite hit it first.

    Running list of Atlas test failures after my big Sinon.JS PR on 5/14/14:

    • account/ order/ views/ pickup-person-view should render pickup person view should validate and submit request Jenkins
    • account/ order/ views/ pickup-person-view should render pickup person view should trigger mobile alert handle on radio selection change Jenkins
    • account/ order/ models/ pickup-person-model Jenkins
    • account/ order/ order-cancellation-view flyout behaviour should show when form validation failed on submit Jenkins Jenkins Jenkins Jenkins
    • account/ order/ order-cancellation-view Selection behaviour should unselect Select All checkbox if any one of the product checkbox is unselected Jenkins
    • account/ order/ order-cancellation-view Selection behaviour should select all product when select all checkbox selected Jenkins
    • account/ order/ order-cancellation-view initialize order cancellation view flyout should not have class active on init Jenkins Jenkins
    • account/ order/ order-detail-cancel initialization behavior should not have class canceled on init Jenkins
    opened by ryan-roemer 38
  • View render now keeps track of user input

    View render now keeps track of user input

    Working on fixing #114.

    This updates the render function to keep track of input data when populate and render has previously been called. Blocks both the populate and serialize events from emitting while the view is rendering (though this could be an option passed in if that fits better).

    The current behaviour for this PR is for the form data to be serialised and filtered for non-empty inputs. This is then merged with the current model state which allows new properties to be defined on the model and render to add the extra property to the form. Also moves the end rendering flag to below the input populating.

    Not sure about the merging behaviour, doesn't seem to fit properly. Thinking that either we should just use the user data without merging new data - or that populate should be update to serialise and merge when no attributes are passed in. Any suggestions?

    opened by blakeembrey 18
  • Always cleanup bindToRoute

    Always cleanup bindToRoute

    If someone is explicitly calling Backbone.history.loadUrl on the same route then the bindToRoute logic will leak as the event handler is never cleaned.

    Since this is something that presumably is relatively rare and backbone itself does some cleanup and routing events in response to this, restructuring the bindToRoute handle so that it will terminate the bound events in response to any route event.

    /cc @eastridge @ryan-roemer @candid

    opened by kpdecker 17
  • Relax bower dependencies.

    Relax bower dependencies.

    Bower dependencies are current directly pinned in bower.json. This makes inclusion in other bower builds problematic, say if the project wants to use jQuery 1.10.2, which causes a hard conflict against the current Thorax dep of 1.9.0.

    Proposal: Review deps in "bower.json" and make more permissive (say greater than known minimum version) for all libraries.

    opened by ryan-roemer 16
  • Destroy stale helper views

    Destroy stale helper views


    This is a tricky problem I hadn't noticed until @Candid pointed out the problems with preserveCollectionElement. Presently each time render is called, new HelperView instances will be generated. In master the stale HelperView instances will not be wiped out, in this branch they will be properly cleaned up.

    I would much prefer that we not destroy old HelperViews and re-embed them ala the view helper. But consider the following view (imagine JS has multiline strings):

    Handlebars.registerViewHelper('test', function(){});
    var view = new Thorax.View({
      template: """
        {{#if key}}
    view.key = true;

    After the first render we have one child view. After the second render we would have two. I can't figure out how to embed the first view back where it was. Instead we nuke it and re-generate the helper views.

    Perhaps the solution is to keep things as is, and re-generate on render. We should then be aware that in this case:

    var view = new Thorax.View({
      collection: new Thorax.Collection(),
      template: '{{#collection}}blah{{/collection}}'

    that the view will be rendered 3 times, and the embedded collection view will be generated 3 times. Once on setCollection and twice on render. Also remember that I've added ensureRendered which will only render if the view has not been rendered once already.

    Also note that for views that render their own collections without the collection helpers the collection will not be re-rendered on render() which is consistent with 1.x behavior.

    opened by eastridge 16
  • Promise on fetch on Thorax.Collections is broken

    Promise on fetch on Thorax.Collections is broken

    The deferred mechanism of default Backbone is not working, see:

    With Backbone.Collection:

    Thorax.Collection: - Uncaught TypeError: Object # has no method 'done'

    Not sure how to test this, maybe in the direction of:

    (I can't get npm test running locally, will look into that later)

    opened by mulderp 13
  • `view.$('input')`.prop('value')` doesn't update on re-render

    `view.$('input')`.prop('value')` doesn't update on re-render

    Not sure if this is a jQuery/Zepto bug, or has something to do with the way Thorax is invoking the libraries.

    Changing an input element's value attribute via pure jQuery works as expected, but as soon as the update goes via a Thorax view's model binding, the results are unexpected:

    • Changing a model attribute (which triggers a view.render()) causes an input value to not update visually (prop() is unchanged), even though the underlying HTML attr() is updated.
    • Calling view.render() causes any subsequent view.$("input").attr() calls to update the view.$("input").attr("value"), but not the view.$("input").prop("value").

    I've created failing test cases and pushed to the branch issue-input-value-after-render.

    To run the test suite:

    git checkout issue-input-value-after-render
    npm install
    bower install
    npm test

    I've added PhantomJS to the package.json in the branch for convenience - is there a reason it is not a dependency in master?

    opened by coopy 13
  • Make serialize non-silent

    Make serialize non-silent

    Need to investigate why serialize is currently set to silent and update to make it non-silent if possible. Otherwise we need to document why we are doing this non-default action.

    opened by kpdecker 13
  • Make unit tests run on IE8

    Make unit tests run on IE8

    Chai doesn't work with IE8, we need to upgrade to latest chai when it comes out or use another lib. Discussion here:

    Note that for what it's worth the sample thorax apps run on IE8.

    opened by eastridge 13
  • Add unit test for model.load bug

    Add unit test for model.load bug

    Sorry for trailing whitespace fixes. I did not do that, Sublime did :)

    This is a unit test for

    I also noticed that in 'data load on route change sends load events' test failback gets called twice, which doesn't seem right.

    opened by candid82 12
  • Fix multiple checked checkbox serialization bug

    Fix multiple checked checkbox serialization bug

    There was an issue serializing a group of checkboxes where there are multiple checked inputs. Previously the last item would overwrite all the other values. It is fixed to provide an array of values.

    I did not attempt to fix populate as I'm sure there might be some discussion on how to do things there.

    opened by gf3 11
  • Announce discontinued maintenance in the readme / docs

    Announce discontinued maintenance in the readme / docs

    This project latest's commit is from February 5th. The 3.0 release, started on Apr 1st, 2014 is still not released (and the docs mix 2.x and 3.x features). A lot of issues doesn't get feedback, and a new release seems highly unlikely.

    I've seen in Thorax pretty neat ideas, and a good overall value. But, right now, with a 2 years old 3.0 in the making never released, I guess something has to be said about it.

    May you please consider stating something at the top of the readme?

    opened by yamsellem 2
  • Rendering a table via collection?

    Rendering a table via collection?

    Some of this behavior was throwing me off. This is using Thorax 2.3.5.


    1. At, I'm trying to be able to render a table correctly, but a div is being added. Why would it create two layers? I'd assume the tag='tr' would be the tagName on the CollectionView.
    2. A second thing I notice is that, if you were to omit a tag in collection, the collection view contents won't render. I would expect it to work and either be a div (or inherit the tagName set in item-View, which would be tr in this example:
    3. I eventually was able to reconfigure it to work, is that how you'd do it? What would be the equivalent of this with a CollectionView? If this does work, are you ok if we add it as an example in the README/docs somewhere?

    I looked into collection-element however the documentation / examples on that are minimal. Would a collection-element play a role in 3?

    opened by tony 1
  • Thorax + Bootstrap, event not correctly trigger

    Thorax + Bootstrap, event not correctly trigger

    Hi, i'm trying to render some btn-group of radio type with Bootstratp, but event change it's doesnt catched by my view , i'm checking , bootstrap triggered event , then jquery to , but i can't catch him :

    my view : ... events { "change input[type=radio]" : "changeLog" }

    then in my view .hbs :

    if someone can help or explain to me ?

    opened by istrion 1
  • Update documentation links

    Update documentation links

    • For the "Server-side Rendering" detail, replace external links with their HTML equivalent
    • Removes a hardcoded link to an old version of Thorax in favor of cdnjs’ UI which defaults to the latest version
    opened by MasterXen 1
  • Form inputs are not updated on re-render

    Form inputs are not updated on re-render

    This looks like as a reincarnation of the issue

    The issue is illustrated by the following failing test:

    The test failure is caused by a bit controversial logic, that preserves the form input element values on rendering: While there’s a reasonable use case for this logic, the suggested test case also seems to be valid. It is also a valid expectation from the user’s standpoint to have the form rendered with the new values, rather than observing old values without an obvious reason.

    What do you think about making this logic optional by default, i.e. allow a flag on the view that would explicitly tell that form data must be preserved?

    /cc @kpdecker @blakeembrey

    opened by dr-nafanya 5
  • HTML5 application architecture using Backbone.js

    An Application Architecture Using Backbone.js Introduction Chaplin is an architecture for JavaScript applications using the Backbone.js library. All i

    Chaplin – JavaScript Application Architecture Using Backbone.js 2.9k Jan 4, 2023
    The Backbone Framework

    Marionette.js The Backbone Framework Marionette v5 Marionette is dropping its dependency on Backbone. That library is available here: https://github.c

    Marionette.js 7.1k Jan 5, 2023
    A rugged, minimal framework for composing JavaScript behavior in your markup.

    Alpine.js Alpine.js offers you the reactive and declarative nature of big frameworks like Vue or React at a much lower cost. You get to keep your DOM,

    Alpine.js 22.5k Dec 30, 2022
    Plugin to backup & restore your strapi installation (database + uploads) from admin panel.

    Strapi Backup & Restore plugin Add backup and restore features directly inside your strapi admin panel. Supported databases: mysql sqlite postgre mong

    Hugues BUREAU 41 Dec 19, 2022
    Utility functions to increase your productivity.

    Focus on being productive instead of busy. Installation npm i devstorm Example // import module import debounce from 'devstorm/debounce'; // debounce

    Salokya Kumar 26 Aug 4, 2022
    Give your JS App some Backbone with Models, Views, Collections, and Events

    ____ __ __ /\ _`\ /\ \ /\ \ __ \ \ \ \ \ __ ___\ \ \/'\\ \ \_

    Jeremy Ashkenas 28k Jan 9, 2023
    Give your JS App some Backbone with Models, Views, Collections, and Events

    ____ __ __ /\ _`\ /\ \ /\ \ __ \ \ \ \ \ __ ___\ \ \/'\\ \ \_

    Jeremy Ashkenas 28k Dec 27, 2022
    HTML5 application architecture using Backbone.js

    An Application Architecture Using Backbone.js Introduction Chaplin is an architecture for JavaScript applications using the Backbone.js library. All i

    Chaplin – JavaScript Application Architecture Using Backbone.js 2.9k Jan 4, 2023
    The Backbone Framework

    Marionette.js The Backbone Framework Marionette v5 Marionette is dropping its dependency on Backbone. That library is available here: https://github.c

    Marionette.js 7.1k Jan 5, 2023
    Seamlessly connect your web server to Rebrandly so that you can re-use your domain name for both your app and your short links

    rebrandly-express Seamlessly connect your web server to Rebrandly so that you can re-use your domain name for both your app and your short links Rebra

    null 3 Dec 13, 2022
    portfolio-project is a npm package to automatically update your projects section in your portfolio website. It will fetch the selected repositories directly from your GitHub account.

    portfolio-project Those days of manually updating portfolio website after every new project made are gone ⚡ Yesss . . . you read that right. ?? portfo

    Gaurav Gulati 15 Aug 3, 2021
    null 8 Nov 11, 2022
    This site compares your GitHub Profile to your friends, and analyses and tells your GitHub profile score too.

    GitHub ⚔️ Duel Deployed at ?? : Compare your GitHub profiles with your friends It gives score to GitHub profile based o

    Anshuman swain 17 Nov 21, 2022
    Give your pages some headroom. Hide your header until you need it

    Headroom.js Headroom.js is a lightweight, high-performance JS widget (with no dependencies) that allows you to react to the user's scroll. The header

    Nick Williams 10.9k Jan 4, 2023
    Guide your users through a tour of your app

    Shepherd is maintained by Ship Shape. Contact us for web app consulting, development, and training for your project. Browsers support Edge Firefox Chr

    Ship Shape 10.8k Dec 28, 2022
    :tada: Add a cute click effect to your mouse in your vuepress!

    vuepress-plugin-cursor-effects ?? Add a cute click effect to your mouse in your vuepress! Document: moefy-vuepress LiveDemo: notev Install yarn add vu

    null 19 Sep 25, 2022
    Easily add filtering, sorting, and pagination to your Node.js REST API through your old friend: the query string!

    QueryQL QueryQL makes it easy to add filtering, sorting, and pagination to your Node.js REST API through your old friend: the query string! Read our i

    Truepic 99 Dec 27, 2022
    Make Your Company Data Driven. Connect to any data source, easily visualize, dashboard and share your data.

    Redash is designed to enable anyone, regardless of the level of technical sophistication, to harness the power of data big and small. SQL users levera

    Redash 22.4k Dec 30, 2022
    Add to your GitHub readme a badge that shows your Discord username and presence (online/idle/do not disturb/offline)!

    Discord Profile Markdown badge Add to your GitHub readme a badge that shows your Discord username and presence! Set up Join the Discord server (requir

    Monty 82 Dec 30, 2022
    Maintain your API development, documentation and experimentation all within your codebase.

    dostman Maintain your API development, documentation and experimentation all within your codebase. This project is a new release! Feel free to contact

    Ege Çavuşoğlu 16 Mar 11, 2022