Есть веб-шаблоны
Независимо от того, используете ли вы двигатель шаблона напрямую или нет, веб-шаблоны всегда там, не на переднем конце, а на задней части. Еще до официального установления стандарта HTML.
Механизм шаблонов на стороне сервера
Самый ранний из известных мне движков веб-шаблонов — это PHP, официально появившийся в 1997 году и работающий на стороне сервера.intro-whatis:
PHP («PHP: Hypertext Preprocessor», аббревиатура от Hypertext Preprocessor) — это широко используемый многоцелевой язык сценариев с открытым исходным кодом, который можно встраивать в HTML, особенно для веб-разработки.
В мире PHP много раз появлялись переупакованные шаблонизаторы, самыми известными из которых являютсяsmarty.
PHPer в целом согласен с тем, что PHP сам по себе является наиболее естественным и естественным механизмом шаблонов PHP, потому что это так.smartyНужно ли существовать?
Многие другие серверные языки имеют механизмы шаблонов HTML, такие какJSP, mustache.
Нет сомнения, что конечным результатом, генерируемым этими серверными механизмами шаблонов, является строка HTML (XML).Логика обработки реализована с использованием синтаксиса самого основного языка.
Общие черты: HTML — это просто строка, конечный результат также может быть похожим.TidyТакой чистый или исправленный инструмент проверки.
Шаблонизатор на стороне браузера
Самый ранний из известных мне шаблонизаторов внешнего интерфейса — этоjCT Размещены в Google Code, не могут быть доступны, родился в 2008 году, базовый язык - JavaScript, работает в браузере. Я имею честь быть автором jCT, связанного с ранним блогомachun, github jCTрезервный.
Я не узнал до сегодняшнего дня, когда писал эту статьюpure-jsВ этой статье также упоминаются многие пионеры,jemplateСоздан как минимум с 2006 года.
сегодня вOSC searchМеханизм шаблонов JavaScript, и вы получите более 100 результатов.
Общая черта: все поддерживают интерполяцию.
Очень разные в других отношениях, с разных точек зрения: слишком много, чтобы охватить
- легкийtpl.js, T.js
- пониманиеarttemplate, mustache.js, doT.js, handlebars.js, pug
- DOM-tree-based domTemplate, transparency, plates
- VDOM-based htmltemplate-vdom, virtual-stache, html-patcher
- популярная рамкаVue.js, ReactJS, riot
- Real-DOM PowJS
здесь такжеtemplating-enginesСравнение популярности (можно добавить). Дажеbest-javascript-templating-enginesГолосование и причины за и против.
как выбрать
Считаю разумным существование.Каждый движок и фреймворк имеет свои достоинства, по крайней мере в вашем приложении, в определенную эпоху.Так что в этой статье не буду комментировать недостатки того или иного движка, это не объективно.
Ниже приведены общие рекомендации по выбору двигателя, и вам необходимо проанализировать несколько вопросов для вашего приложения: пошаговый, пошаговый скрининг
- Предпосылка состоит в том, что выбранный движок может соответствовать требованиям рендеринга данных и не конфликтует с существующими зависимостями.Если вы уже хорошо знакомы с движком, то у вас уже есть ответ.
- Является ли это разовым требованием к проекту? Непосредственно выберите облегченный вариант с наименьшей сложностью обучения.
- Вы занимаетесь разработкой компонентов?
- Движок поддерживает результаты предварительной компиляции, разве вам не нужно каждый раз компилировать в реальном времени?
- Хотите быть кросс-платформенным? Есть официальная поддержка, желательно React-JSX-подобный движок или чистый движок VDOM.
- Выберите вариант с наименьшей сложностью для изучения или сопровождения, и хорошо известно, что разработчики ненавидят, когда отладка занимает больше времени, чем написание кода.
- Последнее сравнение производительности.Сравнение производительности очень детальная работа.Результаты сравнения других могут не совпадать с вашей сценой.
Вопросы, которые, по моему мнению, следует смягчить: при сравнении стилей грамматики предпочтения несопоставимы, а некоторые грамматики даже имеют определенные предпосылки.
Теперь ответ на первый вопрос:smartyНужно ли существовать?.Мой ответ: Да.Причина очень проста,смотрите кто его использует,и посмотрите предысторию.Для приложений которые не отделены от фронтенда и бэкенда,или фронтенд персонал не знаком с внутренним языком или из-за должностных обязанностей, то для внешнего персонала вполне реально освоить относительно распространенный синтаксис (язык) шаблона. Наоборот, пусть PHPer использует его самsmartyЭто было бы пустой тратой навыков.
Почему сравнение производительности в конце?
Производительность действительно очень важна, но если производительность не повлияла на работу вашего приложения, игнорируйте ее.Трудно имитировать сценарии приложений в реальном времени, обычно только с помощью реальных сценариев для тестирования, текущие инструменты тестирования не могут достичь этого эффекта.Если вы найти есть, пожалуйста, порекомендуйте, мне это тоже нужно.
На часть предыдущих вопросов есть фиксированные ответы, а на оставшиеся вопросы: как сравнить разработку компонентов, поддержку прекомпиляции, сложность?
разработка компонента
Разработка компонента больше не является вопросом выбора шаблонизатора, это вопрос выбора экологического окружения.Реальность такова, что ваше приложение должно быть завершено быстрее, и время на первом месте, выберите популярный фреймворк, даже если они предоставляют Компонентов достаточно для использования или ссылки на них.Если ваше приложение имеет независимую экологическую среду и требует выбора технологии для долгосрочного обслуживания, продолжайте читать ниже.
предварительно скомпилировано
Прекомпиляция должна иметь:
- Результаты компиляции в целевой среде больше не требуют процесса компиляции.
- Результаты компиляции поддаются отладке, что означает, что результаты должны содержать собственный код ECMAScript, а не чистое описание данных.
Хорошо известно, что React-JSX поддерживает предварительную компиляцию, и официальное заявлениеReact Without JSX, который всегда строится.
Некоторые движки, основанные на обработке строк, также поддерживают предварительную компиляцию.
Если вам нужна предварительная компиляция, рекомендуется отказаться от движка, результаты компиляции которого по-прежнему основаны на конкатенации строк.Лучше не выполнять предварительную компиляцию, что является выбором до того, как HTML5 не будет широко поддерживаться.
Кроме того, исключительно профессиональноpolyfill.ioЭто может помочь вам решить 99% проблем совместимости браузеров.
По крайней мере, для отладки требуется что-то вроде React-JSX.Примечания: Vue.js поддерживает несколько механизмов шаблонов, которые могут достичь того же эффекта.
Оригинальный код ReactJS: в котором используется концепция веб-компонентов.
class HelloMessage extends React.Component {
render() {
return <div>Hello <x-search>{this.props.name}</x-search>!</div>;
}
}
После компиляции:
class HelloMessage extends React.Component {
render() {
return React.createElement(
"div",
null,
"Hello ",
React.createElement(
"x-search",
null,
this.props.name
),
"!"
);
}
}
Многие движки VDOM также могут компилировать подобные эффекты, такие какhtmltemplate-vdom.
<script>
var id = 3;
var env = {
people: [
{
id: 'id1',
name: 'John',
inner: [{ title: 'a1' }, { title: 'b1' }],
city: 'New York',
active: true
},
{
id: 'id2',
name: 'Mary',
inner: [{ title: 'a2' }, { title: 'b2' }],
city: 'Moscow'
}
],
githubLink: 'https://github.com/agentcooper/htmltemplate-vdom',
itemClick: function(id) {
env.people.forEach(function(person) {
person.active = String(person.id) === String(id);
});
loop.update(env);
}
// Omitted ....
};
</script>
сложность
Трудно использовать единый критерий, чтобы судить, какой из двух движков имеет низкую сложность. Это вызвано разными способами мышления пользователей. Например, различия в использовании и предварительно скомпилированных результатах движков, перечисленных в предыдущей главе, Разные.Ощущения пользователя разные.В этом рациональность и ценность существования этих разных движков.Мир прекрасен из-за различий.
有的使用者认为这个应用场景有字符串模板就满足了需求, 轻量够用.
有的使用者认为字符串拼接技术的模板引擎不够强壮, 不够时代感.
有的使用者认为 OOP 够理性, 够逻辑, 够抽象.
有的使用者认为原生 HTML 才叫前端.
有的使用者认为 VDOM 适用性更广.
Эти суждения имеют свои причины, и их направленность различна, и их стандарты также различны.
Шаблоны строковых классов, как правило, очень легковесны и выходят за рамки этого раздела.
Каков общий критерий оценки сложности нестроковых шаблонов?На мой взгляд, можно рассматривать сложность привязки данных.
В этой статье речь идет о привязке данных не только для интерполяции, но и для контекста и событий, и даже для среды размещения для всего времени выполнения.
На самом деле, чтобы иметь эту возможность, требуется, по крайней мере, механизм уровня VDOM, потому что VDOM могут быть сопоставлены с реальными узлами DOM.
Вероятно, есть несколько режимов (комбинаций):
- Входной параметр — это объект, переменная в шаблоне
xявляется объектом.xсвойство Пример:virtual-stache-example - Определенный синтаксис или свойства, например Vue.js
<a v-on:click="doSomething">...</a>, Атрибутыcomputed,methods - Абстрактные семантические свойства, такие как: Vue.js
activeЭто слово применимо к множеству сценариев, легко для понимания и не вызывает двусмысленности. - Не несет ответственности за привязку, пользователи должны хорошо знать нативные методы и использовать нативные методы для привязки, например: PowJS.
Эти шаблоны являются только теоретическими и обычно являются проблемой для разработчиков шаблонизаторов.Пользователям лучше спросить напрямую:
- Могу ли я написать простейший console.log(context) непосредственно в HTML-шаблоне для отладки?
- Можно ли связать или передать разные параметры контекста в нескольких слоях дерева DOM?
- Можно ли получить доступ к сгенерированному узлу в многоуровневом дереве DOM?
Команда шаблонизатора даст вам правильное решение, но обычно цель отличается от буквального описания проблемы.Я думаю, что это ключ к вашему выбору суждения, вашему признанию правильного метода, данного официалом.
Встроить в DOM
Встроить в HTML
Эти слова в файле сведений о PHP в начале этой статьи.Исторические причины, по которым PHP по-прежнему является препроцессором гипертекста на стороне сервера, а HTML по-прежнему является строкой в PHP.Однако:
HTML с точки зрения PHP — это строка, а PHP действительно органично встраивается в «хост» HTML.
Сегодня, когда отраслевые стандарты WEB совершенны, а среда значительно улучшена, может ли интерфейсный механизм шаблонов прорваться, только встроенный в строки HTML или встроенный в VDOM?
Встроить в DOM
PowJS делает это, и я тожеPowJSДизайнер .PowJS реализует это так:
- Директивы, которые необходимо реализовать для реализации шаблона
- Предварительная компиляция выходного собственного кода ECMAScript
- Структура синтаксиса шаблона соответствует написанию функций ECMAScript.
В конечном счете, написание шаблонов PowJS похоже на написание функций ECMAScript.
GoHub indexправописание в
<template>
<details func="repo" param="data" if="is.object(data.content)&&!sel(`#panel details[sha='${data.sha}']`)"
open
let="ctx=data.content"
sha="{{data.sha}}"
origin="{{ctx.Repo}}"
repo="{{data.owner}}/{{data.repo}}"
subdir="{{ctx.Subdir||''}}"
filename="{{ctx.Filename}}"
render=":ctx"
do="this.renew(sel(`#panel details[repo='${data.owner}/${data.repo}']`))"
break
>
<summary>{{ctx.Description}}</summary>
<div if="':';" each="ctx.Package,val-pkg">
<p title="{{pkg.Progress}}: {{pkg.Synopsis}}">{{pkg.Import}}</p>
</div>
</details>
<dl func="list" param="data"
if="!sel(`#panel details[sha='${data.sha}']`)&&':'||'';"
each="data.content,data.sha,val-rep"
do="this.appendTo(sel('#panel'))">
<details sha="{{sha}}" repo="{{rep.repo}}">
<summary>{{rep.synopsis}}</summary>
</details>
</dl>
</template>
Директивы, которые появляются в шаблоне, не являются чем-то необычным, и это директивы, которые будут реализованы в большинстве шаблонов.
- Глобальные объекты
is,sel - Наименование шаблона (функции)
repo,list - Входной параметр шаблона (функции)
data - пользовательская локальная переменная
ctx - Вывод параметров шаблона (функции) нижнего уровня
data.sha->sha - Значение перехода к вычету параметра шаблона нижнего уровня
(ctx.Package,val-pkg)->pkg;(data.content,val-rep)->rep - Управление узлами DOM
this.renew,this.appendTo, Это отображает непосредственно дерево DOM страницы. - Контроль над процессом
break - псевдоузел
if="':';", вообще не генерируется при рендерингеdivузел, который является псевдоузлом, эквивалентным символу блочного кода "{}"
Key: Вся структура шаблона, семантика директив и функции ECMAScript точно такие же.
- Привязки данных нет, вы пишете функцию ECMAScript, передаете параметры, какую привязку хотите?
- Привязки к событию нет, каждый узел истинен, напрямую пишется AddeventListener.
- Для отладки просто найдите
doилиifилиletвставлять_=console.log(x),Что ж, выражения с запятыми можно без проблем вставлять практически во все нативные операторы. - Представление экспорта — это исходный код ECMAScript, следующее изображение взято из демонстрацииMy Folders
Значит, PowJS — лучший выбор для этого?
Философия PowJS — нативный, нативный DOM, нативный ECMAScript.
Натив также является проблемой PowJS, не всем пользователям нравится натив, я считаю, что некоторые пользователи предпочитают более абстрактный стиль, а натив в их глазах всегда имеет немного «примитивности».
Мое мнение остается:
Ваши потребности являются ключом к выбору шаблона, мир другой и прекрасный