Доклад на девятой конференции «Свободное программное обеспечение в высшей школе», 25–26 января 2014. Исходный код заметок и примеров к ним доступен на https://github.com/mbykov/articles.
- первое знакомство с component — unix way в веб-программировании
- пример создания компоненты
- юнит-тестирование — консоль
- юнит-тестирование — express
- юнит-тестирование — браузер
- make vs. gulp vs. grunt, & watch
- Z's dead, baby
- компоненты и couchapps
Все, кто работает с node.js, знают TJ Головайчука, автора веб-сервера express, библиотеки для тестирования mocha, и прочая, и прочая. Но, наверное, самый блестящий его проект на сегодня — это Component — http://github.com/component. На русском пока немного литературы о Компонентах, попробую восполнить этот пробел. TJ опубликовал первое сообщение о Компонентах в своем блоге 19 декабря 2012 г. Сейчас, после взрывного роста, количество компонент уже зашкаливает за тысячу, и растет каждый день.
Чтобы серьезно работать с JS в браузере, нам нужно, чтобы код был модульным, чтобы каждый модуль находился в своем файле, и чтобы каждый модуль можно было тестировать отдельно, и независимо от остальных. Компоненты — это и есть модули, которые использует браузер, наподобие npm-модулей, которые использует node.js. От модулей, созданных browserify.js компоненты отличаются тем, что в browserify в качестве «исходного материала» используются только npm-модули, в которых может быть только JS, а компонента может включать в себя и css, и html, и шрифты, и все вместе. Это одновременно исправляет то, что css не имеют своей модульной системы. И, например, удаление какой-либо части приложения превращается в проблему. Если вы используете components, удаление компоненты вместе с html, css. etc — почти тривиальное действие.
Компонентой приложения может быть, например, в сетевом магазине — покупательская корзина. Или любая навигационная панель, сложная менюшка и т.д. Важно то, что каждая компонента проектируется и тестируется отдельно. На тестировании компонент я остановлюсь подробнее далее. Но компонента не обязательно должна иметь видимое представление на странице. Преобразование даты или римских цифр, любого локального формата — типичные примеры.
Из двух главных форматов модулей в javascript — CommonJS и AMD — в компонентах выбран первый. Компоненты удобны тем, что и создание, и добавление зависимостей, и публикация, и в значительной степени даже тестирование происходит в привычной командной строке. Работа с components очень похожа на работу с node.js. (Да хоть с Руби или Питоном). Если вы имеете представление о node.js, вы можете работать и с components. Это выгодно — не только один язык — javascript и на сервере, и в браузере, но и привычный workflow, используются все те же навыки. И во многом тот же код. Это выгодное отличие от систем на AMD.
Для первоначального знакомства удобнее всего просмотреть wiki, особенно FAQ.
универсальность
Основное отличие Компонент от многих аналогичных проектов — например, плагинов jQuery, компоненты — это просто компоненты. Плагин jQuery можно использовать только с jQuery. Dojo, Backbone, или MooTools модули — тоже только в соответсвующей инфраструктуре. Компоненты — это просто компоненты. Они не требуют ничего для работы, и их можно использовать везде, с любой системой и с любым фреймворком. Каждую компоненту можно генерировать как standalone скрипт, и использовать его в браузере вообще вне всякой системы.
component.json
В отличие от node.js (и, соответственно, browserify.js), каждый компонент требует наличия файла component.json, подобного файлу package.js. Для тех модулей, которые планируется использовать в обеих средах, и на сервере, в node.js, и в браузере, это ощущается, как перебор. Выигрыш — простой, чистый и ясный код, и в обоих файлах, и в самой компоненте. Спецификация component.json.
пространство имен: github/author/project
Второе заметное отличие — общий репозиторий и пространство имен компонент. В ноде свой репозиторий, npmjs.org, в компонентах по умолчанию — github.com. (Можно использовать свой, конечно). Соответственно, имя компоненты — username/project. Это очень удобно. Имя автора быстро становится узнаваемым, и из нескольких подобных названий можно сразу выбрать по этому «знаку качества».
Дискуссию об этих отличиях с благожелательным диктатором node.js можно прочитать в его блоге и в component-FAQ. Подробную таблицу отличий component vs. browserify подготовил G.Stagas.
лишний этап?
Да, чтобы связать все компоненты приложения в единый build.js, приходится ввести дополнительный шаг — make build. Но мы все равно при работе с javascript неизбежно выполняем предварительные шаги — нам нужно преобразовать кофескрипт, преобразовать sass, прогнать jshint, упаковать, и т.д, и т.д, и т.д. Так что еще одна составляющая этого процесса вообще никак не заметна в работе. Все вместе выполняется всегда всего одной командой make или grunt, gulp, так что это, по большому счету, вообще не недостаток.
размер имеет значение
С компонентами обычно можно не использовать jquery, underscore, etc, etc, etc. Например, если вам нужно использовать each или map — не ставьте для этого jquery, или underscore, но require(component/each) — несколько строк и у вас кроссбраузерный код. И так на каждый метод. В результате:
Angular.js — 709Kb, component/reactive — 47Kb. Reactive — не полный аналог Angular, но лишь его коренная функциональность. Но вам ведь обычно это и нужно, а не весь этот бегемот.
Aloha.js ~ 1Mb, yields/editable — 4.6 Kb, также совсем не полный аналог Aloha, но только суть дела, которая и нужна.
Тут нет опечатки, 1Mb / 4.6Kb. Именно такая чудовищная пропорция.
Вдобавок, уберите опцию --dev при make build. Вдобавок, посмотрит Flatinator Шарлотты Гор, он уменьшает код за счет удаления неиспользуемых алиасов. Вдобавок, в v1 обещана еще большая компактность. Это все до минификации и компрессии.
unix-way
Каждая компонента мала, и выполняет только одну задачу. (Знакомая фраза). В силу этого даже средний проект может требовать до сотни компонент. Но это пугает лишь на первый взгляд. В результате даже для крупного проекта в связанном виде не-минифицированный build.js может весить не более, или около 100 Kb. Компоненты — это не очередной фреймворк, компоненты это unix-way в браузере.
самое главное для меня
Самое главное для меня лично состоит в том, что следуя этому образцу, я могу посмотреть, как грамотные люди выполняют даную конкретную задачу. Найти нужное место в бегемотах вроде Rails, Angular, Django и понять, как это работает, не всегда возможно. Это могут только люди сильные духом, или кому делать нечего. И не часто выпадает возможность разобраться. Работает, и ладно, сделал дело, и вроде и не к чему дальше разбираться. А в компонентах каждая из них — вполне обозримый, простой продукт, на котором легко учиться.
Ну и то, о чем уже было сказано — единый workflow на сервере, в браузере, и, например, в CouchDB — везде работа основана на стандарте CommonJS.
Установка:
<pre>
$ sudo npm install -g component
$ component --help
. . .
</pre>
продолжение следует
P.S. Как правильно, компонент или компонета? посмотрим, что приживется. На грамоте.ру сказано, что «во всех нетерминологических контекстах следует употреблять слово компонент». А здесь именно терминологический контекст. То есть компонент-а, она. Разница особенно заметна во множ. числе — много компонент или компонент-ов. Поскольку я выбираю компонент-у, то во множественном числе выбираем первый вариант — много компонент.
Автор: mbykov
