Pull to refresh

Comments 28

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

Тем не менее, материал качественный и красиво оформленный. А это, нынче, редкость.
Ну почему же? Для небольших приложений и виджетов очень удобно использовать handlebars, зачем тянуть монстра Angular, когда можно обойтись vanilla + шаблонизация?
Но весит больше чем Angular Light.
Angular и React — это целокупные фреймворки, а Handlebars — всего лишь библиотека шаблонизации. У ней меньше идеологии, требующей принятия. Тем она полезнее.

На основную же тему блогозаписи я хочу прибавить свéдение о том, что существует хороший модуль express-handlebars для употребления Handlebars на стороне сервера в тех случаях, когда сервер этот — Express.js.
Основная проблема подобных шаблонизаторов, что они не работают с html, для них входное выражение, это просто строка с ключевыми конструкциями, поэтому очень легко получить невалидный html или попросту битый на выходе.
Так шаблон вы сами собираете, а значит сами делаете невалидный html или я не так понял ваш коммент?
Ну если так рассуждать, то, да, но и инструмент позволил мне это сделать. От шаблонизатора html я ожидаю, что он сообщит мне об ошибках в верстке, например когда «я» неправильно закрыл {{# if}} (уровнем выше или ниже), но он будет молчать, а отлавливать это трудно.
Кстати, когда-то давно мы в конторе много писали на XSLT, и мне неоднократно приходилось обучать юных падаванов его основам. Так вот, ВСЕХ очень напрягал именно тот факт, что шаблон генерирует на выход дерево узлов (и, соответственно, ругается на незакрытые теги), а не последовательность букв. То есть, ожидали ровно обратного.

Правда, в те времена балом правил Smarty :)
Я использую jsRender не помню на какие, но с ходу натолкнулся на ограничение в Handlebars которые меня не устроили.
Вы меня простите, но, как мне кажется, в шаблонизатор надо пихать минимум логики. И если у вас возникает верстка, которая требует подобную логику, то не проще ли вынести эту логику в код?!
Особенно красиво выглядит вынесение таких вещей как проверка длины массива. Идея мне понятна, но доводить её до абсурда не нужно.
Мне кажется, в любом случае, есть решение без реализации такой конструкции
Есть модель

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

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

С хелпером понятно, какие ещё варианты с handlebars? Мне не очень понятно зачем так урезали функционал, в угоду чего?
Это должно решаться не на уровне шаблонизации. В шаблон должны попасть данные, которые нужно отрендерить, без всякой логики в идеале.
Я понимаю идею, но эта урезанность функций view увеличивает bolerplate code. Причем если подумать, то чья эта сфера ответсвенности как не view?
Не понимаю, за что минус…
Это сфера viewModel, model и т.д. как бы это еще не назвалось.
Минус в том чтобы написать вместо чего-то типа {{if sports.length>1}} какую-то неведомую {{ifLengthMoreThanOne}} её где-то определить и тем самым увеличить количества кода и уменьшить его читаемость. Я уж не говорю о том что увеличивается вероятность ошибок и т.д. во время кодирования.
Вы не передавайте данные, если их не нужно рендерить. Разве это не удобнее, если вы только в 1 месте управляете данными, которые должны отрендериться?
Это хорошая идея. Но я не об этом, я о том что могли бы оставить возможность писать условные выражения в «шаблоне», а уже пользователь выбрал бы как ему удобнее. По сути это первое с чем я столкнулся и что сразу же решило буду ли я пользоваться handlebars или нет.
isHaveSportsItems компьютед свойство и все.
И ваша верстка будет более читабельна, чем с условиями.

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

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


а

(arr.length>0) === true


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

{{#if sports.length}}
  your code here
{{/if}}
Это называется костыль :). Модель не должна знать как её отображают.

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

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

Иногда же (в более простом частном случае) используется цикл «{{#each sports}}» по элементам массива, и только наличие общего заголовка их (или общего хвоста) оправдывает условный оператор.
each поддерживает else, который срабатывает когда элементов 0 — об этом мало кто знает/помнит
Там выше был вопрос что делать с {{#if sports.length > 1}}. Это так просто не решить.
В модели добавлять дополнительный флаг не осень хорошо, потому что, во-первых, это будет дублированием информации, а во-вторых может и на сервер случайно отослаться
Only those users with full accounts are able to leave comments. Log in, please.