Handlebars. Руководство к действию

[xamd]

О, мы использовали handlebars в 2011. Но, честно говоря, я думаю что целевая аудитория этой статьи крайне ограничена людьми, которым приходится поддерживать legacy- код на backbone или чем-то подобном. Все современные решения (а-ля angular, react) предоставляют свои инструменты для шаблонизации HTML.

Тем не менее, материал качественный и красиво оформленный. А это, нынче, редкость.

[lega]

Но весит больше чем Angular Light.

[Mithgol]

Angular и React — это целокупные фреймворки, а Handlebars — всего лишь библиотека шаблонизации. У ней меньше идеологии, требующей принятия. Тем она полезнее.

На основную же тему блогозаписи я хочу прибавить свéдение о том, что существует хороший модуль express-handlebars для употребления Handlebars на стороне сервера в тех случаях, когда сервер этот — Express.js.

[DSL88]

Ember.js

[evil_random]

Legacy-код. На Backbone. Ну-ну.

[RubaXa]

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

[RubaXa]

Ну если так рассуждать, то, да, но и инструмент позволил мне это сделать. От шаблонизатора html я ожидаю, что он сообщит мне об ошибках в верстке, например когда «я» неправильно закрыл {{# if}} (уровнем выше или ниже), но он будет молчать, а отлавливать это трудно.

[dubr]

Кстати, когда-то давно мы в конторе много писали на XSLT, и мне неоднократно приходилось обучать юных падаванов его основам. Так вот, ВСЕХ очень напрягал именно тот факт, что шаблон генерирует на выход дерево узлов (и, соответственно, ругается на незакрытые теги), а не последовательность букв. То есть, ожидали ровно обратного.

Правда, в те времена балом правил Smarty :)

[lazant]

Я использую jsRender не помню на какие, но с ходу натолкнулся на ограничение в Handlebars которые меня не устроили.

[lazant]

Вспомнил вот из-за этого: stackoverflow.com/questions/8853396/logical-operator-in-a-handlebars-js-if-conditional

[lazant]

www.jsviews.com/#iftag вот так это решается в jsRender

[DSL88]

Вы меня простите, но, как мне кажется, в шаблонизатор надо пихать минимум логики. И если у вас возникает верстка, которая требует подобную логику, то не проще ли вынести эту логику в код?!

[lazant]

Особенно красиво выглядит вынесение таких вещей как проверка длины массива. Идея мне понятна, но доводить её до абсурда не нужно.

[DSL88]

Мне кажется, в любом случае, есть решение без реализации такой конструкции

[lazant]

Есть модель

{name:'someName',sports:['capoeira','football']}

Отображать нужно только если sports.length>1

С хелпером понятно, какие ещё варианты с handlebars? Мне не очень понятно зачем так урезали функционал, в угоду чего?

[artemmalko]

Это должно решаться не на уровне шаблонизации. В шаблон должны попасть данные, которые нужно отрендерить, без всякой логики в идеале.

[lazant]

Я понимаю идею, но эта урезанность функций view увеличивает bolerplate code. Причем если подумать, то чья эта сфера ответсвенности как не view?

[artemmalko]

Не понимаю, за что минус…
Это сфера viewModel, model и т.д. как бы это еще не назвалось.

[lazant]

Минус в том чтобы написать вместо чего-то типа {{if sports.length>1}} какую-то неведомую {{ifLengthMoreThanOne}} её где-то определить и тем самым увеличить количества кода и уменьшить его читаемость. Я уж не говорю о том что увеличивается вероятность ошибок и т.д. во время кодирования.

[artemmalko]

Вы не передавайте данные, если их не нужно рендерить. Разве это не удобнее, если вы только в 1 месте управляете данными, которые должны отрендериться?

[lazant]

Это хорошая идея. Но я не об этом, я о том что могли бы оставить возможность писать условные выражения в «шаблоне», а уже пользователь выбрал бы как ему удобнее. По сути это первое с чем я столкнулся и что сразу же решило буду ли я пользоваться handlebars или нет.

[DSL88]

isHaveSportsItems компьютед свойство и все.
И ваша верстка будет более читабельна, чем с условиями.

Если вам уж совсем нужно чтобы определять по длине массива, то

(arr.length === 0) === false

а

(arr.length>0) === true

И как следствие

{{#if sports.length}}
  your code here
{{/if}}

[lazant]

Это называется костыль :). Модель не должна знать как её отображают.

Насчет читаемости ifLengthMoreThanOne по сравнению с sports.length>1 можно поспорить, но при сложных условиях, согласен, первый тип записи был бы более читаемым.

[Mithgol]

Всецело поддерживаю мнение о том, что в шаблонах для Handlebars.js следует записывать условие в формате «{{#if sports.length}}» (в значении «если длина массива sports — не нулевая») или «{{#unless sports.length}}» (в значении «если длина массива sports — нулевая»).

Прибавлю, что иногда (в зависимости от модели) может пригодиться вокруг всего соответствующего куска шаблона дополнительная обёртка — оператор «{{#if sports}}» (на тот случай, если массив sports вовсе не был задан в модели).

Иногда же (в более простом частном случае) используется цикл «{{#each sports}}» по элементам массива, и только наличие общего заголовка их (или общего хвоста) оправдывает условный оператор.

[DSL88]

each поддерживает else, который срабатывает когда элементов 0 — об этом мало кто знает/помнит

[justboris]

Там выше был вопрос что делать с {{#if sports.length > 1}}. Это так просто не решить.
В модели добавлять дополнительный флаг не осень хорошо, потому что, во-первых, это будет дублированием информации, а во-вторых может и на сервер случайно отослаться