Backbone это javascript-библиотека для тяжёлых frontend javascript приложений, как например gmail или twitter. В таких приложениях вся логика интерфейса ложится на браузер, что впрочем даёт очень значительное преимущество в скорости интерфейса. А как организовать код, для таких достаточно больших проектов? Который не просто набор глобальных переменных и jquery—DOM связей. Для меня перенос бэкэнда вперёд был довольно непривычен.
Backbone близок по духу еще одной библиотеке для богатого фронта - knockout, но как можно судить по названиям, они отличаются по замыслу. Нокаут занимается активной синхронизацией данных между DOM элементами через ModelView объекты с бэкэндом. "Позвоночник" же отвечает только за достаточную многослойность архитектуры, которую надо программисту унаследовать.
Основные классы
В качестве ядра используются наследуемые "классы"
- Router и History - принимают url и говорят какой view надо запустить
- View - привязывается к dom-элементам и в зависимости от их вложённости отвечает за их данные. Именно View вызываются из Route что-бы открыть прошлое состояние. И именно View реагирует на пользователя через подписку на события ( поле events)
- Collection - массив моделей (не обязательно одинаковых), привязывается к View и может оповещать его об изменениях
- Model - основные классы сущностей, имеют url для получения и изменения данных по RESTful http с backend
View, будучи конечным результатом и наиболее нагруженным классом, напрямую зависит от js-шаблонизатора из underscore библиотеки. Шаблонизатор ничем практически не отличается - только тем что все шаблоны подгружаются сразу в script-тэгах и переменные выделяются <%=foobar%> тэгами с мини-логикой. Начало выглядит примерно так..
MyApp.EditableSpanView = Backbone.View.extend({
template: _.template($('#span_wrapper').html()),
initialize: function(){
this.render();
},
render:function(){
$(this.el).html(this.template(this.model.toJSON()));
}
});
Это объявление View с 1-1 зависимостью с DOM элементом #span_wrapper откуда мы возьмём html конструкцию и модель this.model с данными, которая ещё не задана. Документация backbone не блещет деталями, о том как надо код писать. При создании нового шаблона ему имеет смысл присвоить model или collection если он не общий. Как-то так:
realSpanView = new MyApp.EditableSpanView({model: ItemModel, id:'output' });
Это реализация View. Тут выполнится унаследованные конструктор initialize и рисование в render. Результат будет в элементе с id output — если он уже на странице имеется то в нем, если нет то появится.
События
Backbone имеет своё представление о том как должны распространятся события. Я когда-то писал о сложности этого в DOM. Тут же всё проще. События распространяются двумя путями
- От DOM-элемента через View.events в соответствующий написанный вами View-метод
- От модели или коллекции через подписанные на неё объекты выше (см. диаграмму выше), в т.ч. View
Насчёт первого пункта можно добавить что имеет смысл делать вложенные View-объекты (как группы DOM-деревьев). Например MyBodyView для глобально позиционируемых слоёв, MyListView с коллекцией и MyItemView для конкретного элемента.
По второму пункту - есть магический метод this.bind, который связывает два типа объектов, обычно в initialize. Например MyListView.initialize имеет смысл связать view с коллекцией, что-бы изменение коллекции вызывало изменение view.
this.collection.bind('add', this.add, this);
this.collection.bind('remove', this.remove, this);
Кажется таким очевидным и простым, но этого нет нигде по умолчанию, вы сами должны определить что должно кого оповещать. И хуже всего то, что порой не понимаешь механизма работы платформы. Модели не должны ничего знать о своём отображении, управление идёт наверху - view должен привязать себя к уничтожению и всякому изменению модели
Столкнулся с проблемами
Например вам необходимо постоянно поддерживать свежесть коллекции. Коллекция загружается по url параметру из fetch и дальше вызывается reset где обычно коллекция наполняется опять моделями.
Так вот для того что-бы сделать преобработку данных без перезаписи собственно reset метода, я вешаю bind на reset, вот только аргумент результатов - не json-список и не список переконвертированных моделей у которых распечатать свойства можно только через .get(), а непонятный формат в котором впрочем есть models параметр по которому можной пройтись.
И такого непривычного поведения достаточно что-бы выбить из колеи. То же ключевое слово this - при bind теряется и на самом деле используется связанный объект (коллекция), для этого есть третий параметр или же bindAll из underscore.
Вывод
Библиотека интересная, ограничивающая программистов привыкших к расхлябанному jquery-подходу подвешивания событий на DOM и принуждающая frontend писать едва ли не так же качественно как и backend. Поэтому использовать её стоит в ограниченных условиях, когда надо написать больше JS-кода чем обычно. Альтернативы Backbone — Spine.js, Sproutcore, Cappuccino, EJS. Из "почитать по теме" советую подкаст sitepoint 145, bbtutorials, хабр, а для особо одарённых — про тестирование с Jasmine.