Javascript: тесты, компиляция и MVVM

Доброго времени суток.
Современный мир оставляет мало возможностей не сталкиваться с javascript. Nodejs стал для меня последней каплей и, разочарованный в RoR (слишком много магии и генераторов — никаких холиваров, рубисты!), я снова поддался безумию: один язык на клиенте и сервере. Хоть javascript и прекрасен как язык, фреймворков, которые реализуют MVVM или хотя бы MVC и которые бы мне понравились, нет. Они все тяжеловесны и требуют написания лишнего (мусорного) кода. Поэтому я бы хотел представить на суд мое видение MVVM и получить от сообщества пинков в нужном направлении. Лучшим направлением было бы: «Вы пропустили библиотеку, посмотрите %library_name%», ибо все, что на поверхности (angularjs, knockoutjs, etc.) я посмотрел. Ну а так как фреймворк сырой и вряд ли принесет сейчас кому-то пользу, в обмен на долгожданные пинки я попытаюсь кратко сформулировать свой опыт, полученный при его написании.

Тестирование

Он привез Бильбо уйму носовых платков, любимую трубку и табаку.

Точно так же, как порядочный хоббит не отправится в путешествие без носового платка, жить без тестирования в современном мире можно, но грустно. Думаю, ни для кого не секрет, что браузеры слегка по разному воспринимают javascript, отсюда возникает естественное желание быстро и безболезненно находить проблемы, а не искать их огромным усилием воли, полагаясь на чутье.
В качестве фреймворка для тестирования я выбрал QUnit. Мне очень нравится jquery, и тот факт, что он от jquery foundation стало последней гирькой на чаше весов. Я ни разу не пожалел о выборе, хотя должен сознаться — первое столкновение с асинхронными тестами вызвало у меня легкий шок своим неочевидным поведением, но после внимательного чтения документации все встало на свои места.

Как бы странно это ни звучало, но для старта тестов нам понадобится html документ.

Посмотреть как оно работает можно склонировав репозиторий или тут

Осталось написать свои тесты. Мне очень понравилась идея с группировкой тестов в модуле, метод module. Используем имя файла в качестве имени модуля — и, вуаля, это позволяет достаточно быстро найти отваливающиеся части.
Ну а сам тест пишется с помощью функции test. В официальной документации он достаточно хорошо описан.

Есть у QUnit и приятности, которые греют душу любому программисту. Сконфигурировать что-то под себя всегда приятно, особенно когда хочется быть уверенным, что компилятор послушно выполняет свою роль, а не пытается стать соавтором, поправляя логику, с которой он не согласен.

QUnit.config.urlConfig.push({
    id: "min",
    label: "Minified source",
    tooltip: "Load minified source files instead of the regular unminified ones."
});
QUnit.config.autostart = false;
...
require(
    tests.concat(document.location.href.indexOf("min=true") > 0 ? productionRequire : developmentRequire),
    function() { QUnit.start(); }
);

Все описание, опять же, доступны на сайте проекта тут, но для тех кому лень кликать:

Добавляем checkbox в меню qunit, и если он включен, то в url мы увидим min=true
Отключаем автоматический старт тестов и, в конце концов, появляется замечательная библиотека ruquirejs, с чьей помощью мы загружаем либо скомпилированный код, либо код для разработчиков.

Я не буду приводить тут описание методов ok, equal или deepEqual — на мой взгляд это излишне, если есть полное и понятное их описание тут. Поэтому про тестирование и qunit, наверное, все.

Компиляция кода

Я не знаю. Саруман верит, что только лишь великая сила способна обуздать зло, но мне открылось иное. Я понял, что разные мелочи, житейские деяния простого люда помогают сдерживать тьму. Обыкновенные любовь и доброта. Почему Бильбо Бэггинс? Наверное, потому что мне страшно и он придаёт мне смелости.

Возможно борьба за несколько килобайт в современном мире кажется немного странной, но мы живем в мире, где увеличение времени загрузки сайта на доли секунды снижает количество покупателей на 10-20%, поэтому будем относиться к этому философски, тем более, что это не так сложно.

В качестве компилятора я выбрал Google Closure и получился следующий скрипт:


Собственно, представляет интерес тут только одна строчка, а именно
java -jar libs/compiler.jar --js out/binding.js --js_output_file out/binding-min.js --compilation_level SIMPLE_OPTIMIZATIONS

js — имя компилируемого файла
js_output_file — имя файла, куда положить скомпилированный код
compilation_level — уровень компиляции

Если я пропустил что-то важное для Вас более подробную информацию можно получить выполнив

java -jar compiler.jar --help

BindItJS

Таков был стиль Торина. Он ведь был важной персоной. Если его не остановить, он продолжал бы в том же духе без конца, пока бы совсем не запыхался, но так бы и не сообщил обществу ничего нового.

Я бы не стал критиковать в глаза Торина и, конечно, не буду комментировать успешные и безусловно замечательные существующие фреймворки, без них жить было бы гораздо сложней. Поэтому я предлагаю следующий формат — я буду просто фантазировать о том, как должен выглядеть идеальный (IMHO) фреймворк для биндинга данных.

Скачать о чем пойдет далее речь можно тут
А все примеры я буду приводить из проекта XO, поиграть можно тут

Далее по тексту реверансов «IMHO» не будет, но читая дальше Вы должны понимать, что я пишу субъективное мнение, которое может оскорбить Ваше религиозное или любое другое чувство, и если Вы с чем-то не согласны, я с удовольствием прочитаю Ваш аргументированный комментарий и аргументированно на него отвечу. Все мы тут взрослые люди, ага.

• Код модели и представления должен быть разнесен (SRP)
• Написанный однажды код view должно быть просто использовать повторно (DRY)
• Представление не должно диктовать принцип формирования слоя модели
• Одни и те же данные из модели могут иметь разное представление на странице, без написания дополнительного кода
• Изменение модели должно автоматически дергать соответствующий метод представления

В итоге у нас получается святая троица: html верстка, view, model. Связывать данные и представление через код, когда у нас есть декларативное представление интерфейса мне кажется несколько излишним, поэтому я бы хотел указывать представление и данные в верстке, благо html это позволяет. В итоге у меня получился следующий синтаксис:

<div class="pull-left" bind-data="board" bind-handler="BoardBinding"></div>

bind-data говорит откуда взять данные, а bind-handler как их показать пользователю. Немного подумав про удобство, я ввел еще bind-form, который указывает контекст для дочерних элементов. С атрибутами это все, за исключением того, что bind-handler можно и не указывать, тогда bind-handler будет найден в Binding.DefaultHandlers по имени тэга.

var ButtonBinding = {
    init : function(binding) { binding.element.onclick = function() { binding.callBindingFunction(); } },

    modelChanged : function(binding) {
        if (ObjectUtils.getObjectType(binding.getModel()) != ObjectUtils.TYPE_FUNCTION) {
            binding.element.setAttribute("disabled", "disabled");
            return;
        }

        binding.element.removeAttribute("disabled");
    }
};

Binding.DefaultHandlers["BUTTON"] = ButtonBinding;

<button class="btn btn-success" bind-data="newGame">New game</button>

Давайте внимательно посмотрим на ButtonBinding — у него 2 метода: init, который вызывается при инициализации связи модели и представления, и modelChanged, который вызывается при изменении модели. В данном примере это не используется, но у modelChanged есть два дополнительных аргумента: model — это изменившийся объект, и event — содержит описание события.
Тут стоит пояснить, что связь выстраивается не с самим экземпляром объекта.
В xo у нас есть $data.Game.board — это объект который содержит описание игрового поля. Когда мы нажимаем на кнопку «New game», вызывается метод из $data.Game

newGame : function() {
        this.board = new Board(DEFAULT_SIZE);
        this.state = { player : 0, winner : null };
}

Эта функция создает новый экземпляр, но мы увидим, что был вызван modelChanged соответствующего view, и в качестве объекта, инициирующего событие, будет передан $data.Game, а в event — описание события.

На практике это значит примерно следующее: мы можем быть уверены, что view оперирует данными, указанными в bind-data, а не неким призрачным объектом, который заслуживает только одного внимания, а именно — сборщика мусора.

Текущее состояние и Roadmap

Сейчас это пре-пре-пре-альфа и может измениться все. Цель данной статьи — получить от Вас отклик, удобен будет подобный синтаксис в Ваших проектах или нет, чего не хватает? Библиотека проверена только в chrome.
Roadmap

• Косметический рефакторинг (привести в порядок имена классов — все перенести в bindit)
• Стабилизировать для основных браузеров
• Дополнительная сборка UI (view для основных тэгов input, button etc)
• ...
• PROFIT

Напоследок я бы хотел задать несколько вопросов коллективному разуму:

• Как Вы тестируете UI? Мне очень пригодилась бы библиотека, имитирующая поведение пользователя: клики, ввод текста etc
• Как перевести на русский Roadmap? Меня коробит от «представление» вместо view, но это стандарт де-факто, а русские аналоги roadmap еще хуже