Comments 28
О, мы использовали handlebars в 2011. Но, честно говоря, я думаю что целевая аудитория этой статьи крайне ограничена людьми, которым приходится поддерживать legacy- код на backbone или чем-то подобном. Все современные решения (а-ля angular, react) предоставляют свои инструменты для шаблонизации HTML.
Тем не менее, материал качественный и красиво оформленный. А это, нынче, редкость.
Тем не менее, материал качественный и красиво оформленный. А это, нынче, редкость.
+1
UFO just landed and posted this here
Angular и React — это целокупные фреймворки, а Handlebars — всего лишь библиотека шаблонизации. У ней меньше идеологии, требующей принятия. Тем она полезнее.
На основную же тему блогозаписи я хочу прибавить свéдение о том, что существует хороший модульexpress-handlebars для употребления Handlebars на стороне сервера в тех случаях, когда сервер этот — Express.js.
На основную же тему блогозаписи я хочу прибавить свéдение о том, что существует хороший модуль
+4
Ember.js
0
Legacy-код. На Backbone. Ну-ну.
0
Основная проблема подобных шаблонизаторов, что они не работают с html, для них входное выражение, это просто строка с ключевыми конструкциями, поэтому очень легко получить невалидный html или попросту битый на выходе.
0
UFO just landed and posted this here
Ну если так рассуждать, то, да, но и инструмент позволил мне это сделать. От шаблонизатора html я ожидаю, что он сообщит мне об ошибках в верстке, например когда «я» неправильно закрыл {{# if}} (уровнем выше или ниже), но он будет молчать, а отлавливать это трудно.
0
Кстати, когда-то давно мы в конторе много писали на XSLT, и мне неоднократно приходилось обучать юных падаванов его основам. Так вот, ВСЕХ очень напрягал именно тот факт, что шаблон генерирует на выход дерево узлов (и, соответственно, ругается на незакрытые теги), а не последовательность букв. То есть, ожидали ровно обратного.
Правда, в те времена балом правил Smarty :)
Правда, в те времена балом правил Smarty :)
+1
Я использую jsRender не помню на какие, но с ходу натолкнулся на ограничение в Handlebars которые меня не устроили.
0
Вспомнил вот из-за этого: stackoverflow.com/questions/8853396/logical-operator-in-a-handlebars-js-if-conditional
+1
www.jsviews.com/#iftag вот так это решается в jsRender
0
Вы меня простите, но, как мне кажется, в шаблонизатор надо пихать минимум логики. И если у вас возникает верстка, которая требует подобную логику, то не проще ли вынести эту логику в код?!
0
Особенно красиво выглядит вынесение таких вещей как проверка длины массива. Идея мне понятна, но доводить её до абсурда не нужно.
+1
Мне кажется, в любом случае, есть решение без реализации такой конструкции
0
Есть модель
Отображать нужно только если sports.length>1
С хелпером понятно, какие ещё варианты с handlebars? Мне не очень понятно зачем так урезали функционал, в угоду чего?
{name:'someName',sports:['capoeira','football']}
Отображать нужно только если sports.length>1
С хелпером понятно, какие ещё варианты с handlebars? Мне не очень понятно зачем так урезали функционал, в угоду чего?
+1
Это должно решаться не на уровне шаблонизации. В шаблон должны попасть данные, которые нужно отрендерить, без всякой логики в идеале.
0
Я понимаю идею, но эта урезанность функций view увеличивает bolerplate code. Причем если подумать, то чья эта сфера ответсвенности как не view?
+1
Не понимаю, за что минус…
Это сфера viewModel, model и т.д. как бы это еще не назвалось.
Это сфера viewModel, model и т.д. как бы это еще не назвалось.
0
Минус в том чтобы написать вместо чего-то типа {{if sports.length>1}} какую-то неведомую {{ifLengthMoreThanOne}} её где-то определить и тем самым увеличить количества кода и уменьшить его читаемость. Я уж не говорю о том что увеличивается вероятность ошибок и т.д. во время кодирования.
+2
Вы не передавайте данные, если их не нужно рендерить. Разве это не удобнее, если вы только в 1 месте управляете данными, которые должны отрендериться?
0
Это хорошая идея. Но я не об этом, я о том что могли бы оставить возможность писать условные выражения в «шаблоне», а уже пользователь выбрал бы как ему удобнее. По сути это первое с чем я столкнулся и что сразу же решило буду ли я пользоваться handlebars или нет.
0
isHaveSportsItems компьютед свойство и все.
И ваша верстка будет более читабельна, чем с условиями.
Если вам уж совсем нужно чтобы определять по длине массива, то
а
И как следствие
И ваша верстка будет более читабельна, чем с условиями.
Если вам уж совсем нужно чтобы определять по длине массива, то
(arr.length === 0) === false
а
(arr.length>0) === true
И как следствие
{{#if sports.length}}
your code here
{{/if}}
0
Это называется костыль :). Модель не должна знать как её отображают.
Насчет читаемости ifLengthMoreThanOne по сравнению с sports.length>1 можно поспорить, но при сложных условиях, согласен, первый тип записи был бы более читаемым.
Насчет читаемости ifLengthMoreThanOne по сравнению с sports.length>1 можно поспорить, но при сложных условиях, согласен, первый тип записи был бы более читаемым.
0
Всецело поддерживаю мнение о том, что в шаблонах для Handlebars.js следует записывать условие в формате «{{#if sports.length}}» (в значении «если длина массива sports — не нулевая») или «{{#unless sports.length}}» (в значении «если длина массива sports — нулевая»).
Прибавлю, что иногда (в зависимости от модели) может пригодиться вокруг всего соответствующего куска шаблона дополнительная обёртка —оператор «{{#if sports}}» (на тот случай, если массив sports вовсе не был задан в модели).
Иногда же (в более простом частном случае) используетсяцикл «{{#each sports}}» по элементам массива, и только наличие общего заголовка их (или общего хвоста) оправдывает условный оператор.
Прибавлю, что иногда (в зависимости от модели) может пригодиться вокруг всего соответствующего куска шаблона дополнительная обёртка —
Иногда же (в более простом частном случае) используется
0
each поддерживает else, который срабатывает когда элементов 0 — об этом мало кто знает/помнит
+1
Там выше был вопрос что делать с {{#if sports.length > 1}}. Это так просто не решить.
В модели добавлять дополнительный флаг не осень хорошо, потому что, во-первых, это будет дублированием информации, а во-вторых может и на сервер случайно отослаться
В модели добавлять дополнительный флаг не осень хорошо, потому что, во-первых, это будет дублированием информации, а во-вторых может и на сервер случайно отослаться
0
Sign up to leave a comment.
Handlebars. Руководство к действию