Еволюцията на системите за шаблони за JavaScript
Има много различни шаблонни системи.
Те постепенно се развиват и развиват.
В тази глава ще анализираме как протича този процес, кои шаблони са „родени“, какви бонуси ни дават, като използваме една или друга система от шаблони.
микромодели
Микрошаблони (английски microtemplate) вече видяхме на примера на _.template.
Това е HTML с вмъквания на променливи и произволен JS.
Предимства и недостатъци на този подход:
- Проста и бърза система за шаблони
- Вътре в JS функцията е наличен пълноправен браузър за отстраняване на грешки, функцията, макар и страшна, е разбираема.
Код в шаблон
Включването на произволен JS код в шаблон на теория ви позволява да правите каквото искате в него. Но обратната страна на монетата е, че един шаблон вместо разбираем HTML може да се превърне в адска купчина разделители, смесени с изчисления. Какво се препоръчва в шаблоните и какво не?
Можем да разделим кода на два типа по отношение на шаблоните:
- Бизнес логика – код за генериране на данни, код на основното приложение.
- Презентационна логика – код, който описва как се показват данните.
Например кодът, който получава данни от сървъра за показване в таблица, е бизнес логика, а кодът, който форматира дати за изход, е логика на представяне.
В шаблоните е разрешена само презентационна логика.
Кръстосана платформа
Често трябва да използвате един и същ шаблон както в браузъра, така и на сървъра.
Този проблем може да бъде заобиколен. На сървър, който използва PHP, Ruby, Java или друг език, допълнително се инсталира V8 виртуална машина и се конфигурира интеграция с нея. Почти всички платформи правят това.
Този подход може да изглежда изкуствен, но всъщност е доста жизнеспособен иизползвани в редица големи проекти.
предкомпилация
Този шаблон и повечето други системи, които ще разгледаме по-нататък, позволяват предварително компилиране.
Тоест, възможно е предварително, преди да качите сайта на „бойния сървър“, да обработите шаблоните, да създадете JS функции от тях, да ги комбинирате в един файл и след това да ги използвате в „бойната среда“.
Съвременните системи за изграждане (brunch, grunt с плъгини и други) ви позволяват да правите това удобно, както и да съхранявате шаблони в различни файлове, всеки в правилната директория с JS кода за джаджата.
Помощници и филтри
За да направят шаблоните по-малки и по-прости, към тях са добавени филтри и помощни средства.
Помощник (англ. helper) е спомагателна функция, която е налична в шаблони и се използва за решаване на често срещани задачи.
В _.template, за да декларирате помощник, можете просто да направите глобална функция. Но това е твърде грубо, те не го правят. Много по-добре е да използвате обекта _.templateSettings.imports, който ви позволява да посочите кои функции да добавите към шаблони, или опцията за импортиране за _.template.
Пример за помощник е функцията t(phrase), която превежда фраза на текущия език:
Филтър е функция, която трансформира данни, като форматиране на дата, сортиране на елементи от масив и т.н.
Обикновено има специален "изключително прост и кратък" синтаксис за филтри.
Например в системата за шаблони EJS, която по същество е същата, но по-мощна от _.template, филтрите са посочени с вътре в разделител.
За да пишете елемент с главни букви, можете вместо това да напишете . За да изведете сортиран масив, можете да използвате и т.н.
Шаблонът за меню в Handlerbars, например, ще изглежда такаТака:
Има и други помощници, вградени в системата за шаблони, можете лесно да направите своя собствена.
Използване на модел като този:
Забрана на вграден JS
Ако „вашият собствен шаблонен език“ е много прост, тогава библиотека, която да го поддържа, може лесно да бъде написана за PHP, Ruby, Java и други езици, които по този начин ще се научат да разбират такива шаблони.
Ако шаблонът наистина е междуплатформен, тогава изричните JS извиквания не са разрешени в него. Всичко става чрез помощници.
Това създава определени трудности. Например Handlebars има помощник > . > , който извежда съдържанието, ако условието е вярно. В този случай вместо cond не можете да поставите например > b или извикването на str.toUpperCase() ще се провали. Всички изчисления трябва да се извършват на етапа на предаване на данни към шаблона.
Това се прави само за преносимостта на шаблонната система на други езици, но на практика не е много удобно.
Усъвършенстваните междуплатформени шаблонни машини, по-специално Closure Templates, имат по-мощен език и могат сами да анализират и компилират много изрази.
Шаблониране на компоненти
Досега говорихме за шаблонни системи с "общо предназначение". Като цяло това са само механизми за преобразуване на един низ в друг. Но когато описваме шаблон за компонент, искаме да генерираме не просто низ, а DOM елемент и не просто да генерираме, но по-късно да работим с него.
Съвременните шаблонни системи са „заточени“ за това. Те могат да създават DOM елементи според шаблон и автоматично да извършват различни полезни действия след това.
Една от първите системи за шаблони, които поддържаха тези функции, беше Knockout.JS.
Опитайте да промените стойността в примера по-долу и ще видитедвупосочно обвързване на данни в действие: