Backbone.js

#javascript

Backbone это javascript-библиотека для тяжёлых frontend javascript приложений, как например gmail или twitter. В таких приложениях вся логика интерфейса ложится на браузер, что впрочем даёт очень значительное преимущество в скорости интерфейса. А как организовать код, для таких достаточно больших проектов? Который не просто набор глобальных переменных и jquery—DOM связей. Для меня перенос бэкэнда вперёд был довольно непривычен.

Backbone близок по духу еще одной библиотеке для богатого фронта - knockout, но как можно судить по названиям, они отличаются по замыслу. Нокаут занимается активной Позвоночни же отвечает только за достаточную многослойность архитектуры, которую надо программисту унаследовать.

Основные классы

В качестве ядра используются наследуемые "классы"

  • 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. Тут же всё проще. События распространяются двумя путями

  1. От DOM-элемента через View.events в соответствующий написанный вами View-метод

  2. От модели или коллекции через подписанные на неё объекты выше (см. диаграмму выше), в т.ч. 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 должен привязать себя к уничтожению и всякому изменению модели

Столкнулся с проблемами

Получение данных на бэкэнде из модели приходят вовсе не в POST, а экзотически

$params = (array)json_decode(file_get_contents('php://input'));

Например вам необходимо постоянно поддерживать свежесть коллекции. Коллекция загружается по 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.