HabHub
HabHub copied to clipboard
nin-jin
Карго-культ HTML в современном фронтенде
https://page.hyoo.ru/#!=xl437w_w1mpfo
Здравствуйте, меня зовут Дмитрий Карловский и я.. люблю рвать шаблоны. А во фронтенде как раз крайне много заблуждений вокруг шаблонизации. Так что давайте порвём их на лоскуты снизу вверх и справа налево.
Далее мы разберём что такое шаблоны. Их ключевые достоинства и фатальные недостатки. Зачем они нужны и почему не нужны. Сформируем представление о правильном решении и проедемся катком по популярным. Так что полная гамма чувств нам обеспечена.
Прошу к столу..
А что такое шаблон?
Казалось бы, тут всё очевидно: это способ генерации кода на целевом языке. Однако, всё не так просто. Чтобы понять ключевое свойство шаблона, давайте рассмотрим пару примеров..
Это шаблон:
"Hello, ${name}!"
А это уже нет:
"Hello" + name + "!"
Оба кода делают одно и то же, но почему одно является шаблоном, а другое - нет? Всё дело в том, какой язык является первичным в коде, а какой является опциональной добавкой к нему. Шаблон предполагает написание кода сразу на целевом языке, вкрапляя в него специальные управляющие конструкции, которые тем не менее синтаксически согласованы с целевым языком.
Яркий пример синтаксически согласованных управляющих конструкций можно наблюдать в XSLT:
<xsl:template name="page">
<acticle>
<h1>
<xsl:copy-of select="./head" />
</h1>
<xsl:copy-of select="./body" />
</article>
</xsl:template>
А вот такой код, не смотря на использование шаблонов в 1 и 3 строке, в целом шаблоном всё же не является, так как чтобы понять, каков будет результат, нужно мысленно корректно исполнить JSX-код:
const head = <h1>{ headContent }</h1>
const body = 'Hello, World'
const article = <article>{ head }{ body }</article>
Грубо говоря, если взять парсер целевого языка, то он справится и с парсингом шаблона, просто проигнорировав управляющие шаблонные конструкции, никак их не обрабатывая. И, соответственно, человек тоже может буквально видеть получающийся из шаблона результат, а не собирать его в уме.
Как видно в последнем примере, код на JSX может быть шаблоном, а может им и не быть. И как правило шаблоном он всё же не является, не смотря на синтаксическое подражание HTML.
А необходим ли HTML?
Во фронтенде целевым языком для шаблонов как правило является HTML. А HTML является не более, чем сериализованным представлением DOM дерева. И в прошлом именно HTML был языком коммуникации между клиентом и сервером. Поэтому серверу нужно было генерировать именно его.
Однако, в современном вебе клиент и сервер больше не обмениваются HTML, предпочитая JSON, ProtoBuf и другие более эффективные форматы. Более того, теперь клиент уже сам формирует DOM напрямую, через JS-API, минуя HTML представление. А это значит, что в качестве целевого языка описания DOM может быть использован не только HTML, но и иные форматы сериализации DOM.
Например, HAML:
!!!
%html{ :lang => "ru" }
%head
%title= title
%meta{ 'http-equiv' => 'Content-Type', :content => 'text/html' }/
%body
%h1= title
%p= description
Или xml.tree:
! DOCTYPE html
html
@ lang \ru
head
title ? title
meta
@ content \text/html; charset=utf-8
@ http-equiv \Content-Type
body
h1 ? title
p ? description
Или даже JSON. Без примера, ибо слишком уж он развесистый получается.
В этом свете использование HTML-шаблонизации является скорее данью традиции, чем реальной необходимостью:
<!DOCTYPE html>
<html lang='ru'>
<head>
<title>{title}</title>
<meta
content='text/html; charset=utf-8'
http-equiv='Content-Type'
/>
</head>
<body>
<h1>{title}</h1>
<p>{description}</p>
</body>
</html>
А достаточно ли HTML?
Мощности HTML хватает лишь для описания DOM. Но современная разработка предполагает компонентную декомпозицию. А где декомпозиция - там и композиция. То есть нам необходим инструмент для создания экземпляров компонент, их настройки и соединения друг с другом реактивными связями разных направлений.
Тут не то что HTML, а даже DOM уже катастрофически не хватает, что неизбежно порождает чудовищ. Например, вам нужно вставить несколько компонент и провязать их состояния друг с другом.
Возьмём ангуляровский "шаблон":
<bi-panel class="example">
<check-box
class="editable"
side="left"
[(checked)]="editable"
i18n
>
Editable
</check-box>
<text-area
#input
class="input"
side="left"
[(value)]="text"
[enabled]="editable"
placeholer="Markdown content.."
i18n-placeholder="Showed when input is empty"
/>
<div
*ngIf="text"
class="output-label"
side="right"
i18n
>
Result
</div>
<mark-down
*ngIf="text"
class="output"
side="right"
text="{{text}}"
/>
</bi-panel>
Весьма похоже на HTML, но только это не HTML, чтобы там ни говорили Angular-евангелисты. DOM (и как следствие HTML) поддерживают лишь задание строк в качестве атрибутов. А для компонент нужны не только строки, но и другие типы данных: числа, объекты и даже другие компоненты. И их надо не только хардкодить в шаблоне, но и брать из свойств, класть в свойства, а то и вообще обеспечивать двустороннее связывание.
И тут начинаются кастомные расширения HTML. Каждый атрибут в примере выше имеет свою семантику, но синтаксически выглядят они все одинаково:
-
#input- это локальный идентификатор, для доступа через TS. -
class="editable"- это имя класса для привязки стилей через CSS. -
side="left"- это имя слота, куда этот элемент будет помещён. -
[(checked)]="editable"- это двустороннее связывание свойств вложенного и внешнего компонентов. -
[enabled]="editable"- это уже одностороннее. -
text="{{text}}"- а это тоже самое. -
placeholer="Markdown content.."- это какой-то захардкоженный текст. -
i18n-placeholder="Showed when input is empty"- а это, внезапно, указание, что атрибутplaceholderподлежит переводу, и пояснение переводчику. -
*ngIf="text"- это же вообще к компоненту не относится, а регулирует будет ли компонент рендериться в родителе.
Все 4 компонента лежат вперемешку, не смотря на то, что часть из них относится к левому слоту, а часть к правому. То есть это мало того, что не HTML, так это ещё и вовсе не шаблон. Это - язык для компоновки компонент, мимикрирующий под HTML. Из-за этой мимикрии он преисполнен горой сомнительных решений, осложняющих изучение, разработку, чтение и поддержку как самого прикладного кода, так и инструментария, превращающего эти "шаблоны" во что-то, что может исполнить браузер, чтобы показать интерфейс.
Но чем же HTML хорош?
Ключевое достоинство HTML - его декларативность. Вопреки расхожему мнению, декларативные языки описывают на самом деле не "результат", а некоторую семантическую структуру. И эта структура может быть использована для программного анализа с получением множества разных "результатов" в зависимости от потребностей.
Мы можем взять HTML и нарисовать на экране красивый плоский интерфейс. Можем в VR показать объёмный интерфейс, который можно потрогать. Можем реализовать голосовой интерфейс для не зрячих. Можем распечатать в виде книги. Можем собрать все заголовки для формирования оглавления и все термины для тезауруса. Можем собрать все ссылки и уведомить сайты, куда они ведут, о том, откуда на них ссылаются. Можем отправить уведомление всем упомянутым пользователям. И много чего ещё.
Но всё это многообразие возможностей крайне затруднено, а то и попросту не возможно при написании императивного кода, который описывает конкретные действия по получению одного конкретного результата. Что бы там ни говорили адепты функционального программирования, но оно ни в коем разе не является декларативным. ФП - это просто императивное программирование на иммутабельных структурах, описывающее конкретные действия, по трансформации заданных входных параметров в заданные выходные. Всё, что можно сделать с чистой функцией - это её исполнить. А всё, что может дать нам анализ её кода - это "ну, там вызываются какие-то функции, вот их сигнатуры".
Простой пример императивного функционального кода:
приготовить_яичницу = ()=> последовательность(
()=> яйцо ,
яйцо => разбей( яйцо ) ,
разбитое_яйцо => уберать_скорлупу( разбитое_яйцо ),
яйцо_без_скорлупы => пожарить( сковорода )( яйцо_без_скорлупы ),
жаренное_яйцо => добавить_приправы( жаренное_яйцо )
)
А вот пример настоящего декларативного кода в модели RDF:
яичница
включает
жареное_яйцо
приправы
жареное_яйцо
создаётся_посредством
горячая_поверхность
скворода
является
горячая_поверхность
жареное_яйцо
создаётся_из
яйцо_без_скорлупы
яйцо
включает
яйцо_без_скорлупы
скорлупа
Это логические триплеты. Благодаря нормализованному представлению их очень просто парсить и анализировать.
Но вернёмся к нашим шаблонам. Возьмём популярный сейчас JSX, который мимикрирует не только под HTML, но и под JS, и даже под ФП, при этом ничем из упомянутого не являясь:
const Example = ( props: {
className?: string
text?: string
onTextChanged?: ( next: string )=> void
editable?: boolean
onEditableToggle?: ( next: boolean )=> void
} )=> {
const [ stateText, setStateText ] = useState( props.text ?? '' )
const [ stateEditable, setStateEditable ] = useState( props.editable ?? true )
const [ inputElement, setInputElement ] = useState< HTMLTextAreaElement >( null )
const className = ( props.className ?? '' ) + ' example'
const text = props.text ?? stateText
const editable = props.editable ?? stateEditable
const setText = useCallback( ( next: string )=> {
setStateText( next )
props.onTextChanged?.( next )
}, [ props.onTextChanged ] )
const setEditable = useCallback( ( next: boolean )=> {
setStateEditable( next )
props.onEditableToggle?.( next )
}, [ props.onEditableToggle ] )
return (
<BiPanel
className={ className }
left={
<>
<CheckBox
className="editable"
checked={ editable }
onToggle={ setEditable }
>
{ l10n( 'Editable' ) }
</CheckBox>
<TextArea
ref={ setInputElement }
className="input"
value={ text }
onChange={ setText }
enabled={ editable }
placeholder={ l10n( 'Markdown content..' ) }
/>
</>
}
right={
text
? <>
<div
className="output-label"
>
{ l10n( 'Result' ) }
</div>
<MarkDown
className="output"
text={ text }
/>
</>
: <></>
}
/>
)
}
Закроем пока глаза на объёмность и сложность кода. Давайте подумаем, что мы можем получить из него без исполнения..
Можем ли мы при сборке вытащить все локализуемые тексты и заменить их на персистентные ключи?
Нет. Даже если мы распарсим весь код в AST, найдём все вызовы функции l10n и понадеемся, что передан ей всегда будет лишь строковый литерал, а не какое-нибудь выражение, нам всё равно неоткуда взять персистентную информацию для формирования ключей, чтобы они не менялись при каждом изменении вёрстки.
Можем ли мы в визуальном конфигураторе понять, что свойства
CheckBox.checked,TextArea.enabledиprops.editableсвязаны друг с другом двусторонней связью?
Нет. И не верьте адептам Реакта, утверждающим, что двустороннего связывания там нет, и что оно вообще не нужно. Оно и нужно, и есть, хоть и реализуется через костыли с парными пропсами вида checked={ editable } onToggle={ setEditable }.
Можем ли мы там же понять, что если не задать свойство
editable, то текстария будет изначально редактируемой?
Нет. Разве что очень сильно заморочиться и реализовать data-flow анализ. И то он будет справляться далеко не со всем многообразием возможного кода.
Можем ли мы при сборке проверить, что CSS-селектор
.example .output .linkдействительно на что-то матчится?
Нет. Так как имена классов собираются из строк в прикладном коде.
Продолжать можно долго, но суть уже должна быть ясна: императивные языки содержат слишком мало информации о высокоуровневых абстракциях и слишком много низкоуровневого шума. Это капитально осложняет программный анализ.
А возможна ли декларативность?
Чем меньше язык позволяет вольностей, тем проще его программно анализировать. Но обратная сторона этого - снижение гибкости. Чтобы достичь максимальной гибкости, нужен язык общего назначения. Во фронтенде таким языком обычно является JS и другие языки, в него компилирующиеся. Поэтому очень велик соблазн либо собирать компоненты сразу в нём, либо засовывать в "шаблоны" вкрапления на JS. Разумеется ни о какой декларативности в этом случае уже говорить не приходится.
Чтобы добиться гибкости, но не потерять декларативность, нужно разбивать код компонента на 2 части:
- Декларативная, где происходит компоновка компонент друг с другом.
- Императивная, где описывается логика работы.
Именно поэтому надо отделять "шаблоны" от "скриптов", а не потому, что одно как бы бизнес-логика, а другое - её отображение.
Для примера возьмём язык view.tree, используемый в $mol:
$my_example $mol_view
sub /
<= Panel $my_bipanel
left <= input /
<= Editable $mol_check_box
checked?val <=> editable?val true
title @ \Editable
<= Input $mol_textarea
hint @ \Markdown content..
value?val <=> text?val \
enabled <= editable
right <= output /
<= Output_label $mol_paragraph
sub / <= output_label @ \Result
<= Output $mol_text
text <= text
Он мало того, что в несколько раз меньше эквивалентного JSX кода, так из него ещё и легко вычленять локализацию, собирать статистику использования, проверять переопределения стилей и много чего ещё. Можно даже построить конфигуратор позволяющий взять произвольное существующее приложение и, не написав ни строчки кода, собрать из него что-то новое. Ну а когда декларативных возможностей не хватает - всегда можно написать комплексную логику в отдельном скрипте, используя всю мощь языка общего назначения:
export class $my_example extends $.$my_example {
output() {
return this.text() ? super.output() : []
}
}
К сожалению, с подачи Фейсбука вместо чего-то такого мы имеем сейчас повсеместный императивный JSX и кучу костыльных проектов, пытающихся его программно анализировать. А в тех фреймворках, где есть отделение скриптов от шаблонов, вместо шаблонов мы видим императивный недо-DSL мимикрирующий под HTML, что приверженцы Реакта справедливо считают бессмысленным.
Что опять за наезды на JSX?
Раз уж мы уже наехали, то не будем останавливаться и проедемся до конца, по всем недостаткам дизайна JSX помимо недекларативности...
Push семантика
Вложенное поддерево вычисляется безусловно, даже если оно завёрнуто в компонент, который показывает своё содержимое лишь иногда. Решаться это могло бы через передачу замыкания вместо VDOM:
return (
<Dialog visible={ opened } >
{ ()=> <>Heavy content</> }
</Dialog>
)
Но, как всегда, есть "но":
- Заворачивать всё подряд в замыкания банально не удобно.
- Замыкания нужно мемоизировать через useCallback, чтобы избежать лишних рендеров.
- Без автоматического трекинга зависимостей это просто не будет работать.
- Изменение получения VDOM на замыкание меняет API компонента.
В результате реальный код становится куда более страшным:
const dialogContent = useCallback( ()=> (
<>Heavy content</>
) )
return userObserver( ()=> (
<Dialog visible={ opened } >
{ dialogContent }
</Dialog>
) )
Сравнение push и pull семантики - это отдельная большая тема. Поэтому вкратце обрисую преимущества pull: она позволяет просто и эффективно реализовать ленивые вычисления, рендеринг, загрузку и вообще экономить ресурсы. У push семантики же с этим всем серьёзные проблемы.
Неэффективность
JSX компилируется в крайне не удачный JS код, который из-за своей мегаморфности крайне сложно поддаётся оптимизации JIT-компилятором:
Сверху - то, каким он мог бы быть быстрым при мономорфности. А снизу - суровая реальность в FireFox.
Слабые возможности связывания
JSX заточен под проталкивание значений. Но любые другие связывания - это боль. Хочешь передать замыкание - изволь завернуть его в useCallback и описать отдельным массивом всё, от чего оно зависит (и счастливой отладки, если что-то забудешь):
const setName = useCallBack( ( name: string )=> {
setInfo({ ... info, name })
}, [ info, setInfo ] )
return <Input value={ info.name } onChange={ setName }>
Самое забавное, что useCallback тут должен спасать от лишних рендеров, но так как замыкание зависит от info, то его приходится указывать в зависимостях, что приводит к обновлению замыкания при каждом изменении данных, даже если info.name фактически не поменялся. А следовательно рендер Input будет происходить при каждом изменении любого поля info.
Про двустороннее связывание я ранее уже упомянул, что оно делается через костыли с прокидыванием пары свойств. Это мало того, что многословно, так ещё и легко разъезжается, приводя ко крепким обнимашкам с дебаггером.
Неконсистентность
Из-за подражания HTML константные строки прокидываются одним синтаксисом, а все остальные типы и неконстантные строки — другим:
<input type="password" minLength={ 5 } className={ 'password ' + className } />
Дочерние компоненты могут быть переданы двумя совсем разными способами:
<Dialog>
<Hello />
<World />
</Dialog>
<Dialog
children={[
<Hello />,
<World />,
]}
/>
А уж сколько есть вариантов условного рендеринга - один хуже другого.
Всё это - следствие попытки усидеть сразу на двух стульях: HTML и JS.
Костыли для комментариев
Набирать и читать их просто неудобно:
<Dialog>
<Hello />
{/* World */}
</Dialog>
Волшебные атрибуты
JSX никак не форсирует простановку уникальных идентификаторов вложенным компонентам. А потребность получать ссылку на конкретный DOM элемент есть. Поэтому в вёрстке появляются волшебные атрибуты:
<Dialog>
<Hello ref={ setHelloRef } />
<World ref={ setWorldRef } />
</Dialog>
По той же причине, функция рендеринга не может отличить перемещённый элемент от нового, что приводит к лишнему рендерингу. Чтобы этого избежать вводится ещё один волшебный атрибут:
<Dialog>
<Message key="hello">Hello</Message>
<Message key="world">World</Message>
</Dialog>
Правда, при переносе в другого родителя, не спасает и он.
И беда даже не в том, что эти атрибуты вообще существуют, а в том, что синтаксически они неотличимы от любых других.
Много мусора в вёрстке
Мало нам закрывающих тегов из HTML. Давайте добавим ещё и лесенку из контекстов:
<ThemeContext.Provider value={theme} >
<UserContext.Provider value={signedInUser} >
<Layout />
</UserContext.Provider>
</ThemeContext.Provider>
<ThemeContext.Consumer>
{ theme => (
<UserContext.Consumer>
{ user => (
<ProfilePage user={user} theme={theme} />
) }
</UserContext.Consumer>
) }
</ThemeContext.Consumer>
Отсутствие ограничений
Отсутствие синтаксических ограничений мало того, что затрудняет программный анализ, так ещё и неизбежно приводит к ухудшению качества кода. Даже если код пишет не говнокодер, порой бывает, что некогда или лень делать правильно, а срезать угол ничего не мешает, и выглядит это вроде бы проще. Но разбитое окно тут, покосившееся там, и вот у нас уже не чётко структурированный код, а лютая тормозящая лапша, где всё связано со всем, лежит вперемешку, но концы с концами фиг сведёшь:
<div className="tag-list">
{tags.map((tag) => (
<button
key={tag}
className="tag-pill tag-default"
onClick={() =>
dispatch({
type: 'SET_TAB',
tab: { type: 'TAG', label: tag },
})
}
>
{tag}
</button>
))}
</div>
В цикле хреначим немемоизированное замыкание, код которого тут же по среди "вёрстки" и всё, что он делает, - меняет формат события. Не, ну а что, подумаешь ререндер всех элементов на каждый чих. Процессоры сейчас быстрые, данных мало, переход к определению работает везде..
А view.tree прям такой идеальный?
Нет, конечно, педаль в пол, давим и его..
Слабая интеграция с IDE
Microsoft добавила поддержку JSX прямо в компилятор TypeScript, что дало не только хороший тайпчек, но и интеграцию в тайпскриптовый Language Server. А это значит отличную интеграцию не только с их же VSCode, но и с другими IDE.
К сожалению, Microsoft не озаботилась простотой интеграции сторонних языков с TS. view.tree, конечно, компилируется в TS, что даёт тайпчек при сборке, но IDE этого всего не видит. Соответственно, не работают подсказки, рефакторинги и тп. Хорошо хоть подсветка синтаксиса есть.
Неявная типизация
Во имя простоты и наглядности в языке почти нет возможности задать тип явно. Типы выводятся из значений по умолчанию, что не всегда даёт ожидаемый результат.
Например, значение null имеет тип any:
/**
* Placeholder null
*/
Placeholder() {
return null as any
}
Как и аргументы методов:
/**
* name!id?next \Unknown
*/
@ $mol_mem_key
name(id: any, next?: any) {
if ( next !== undefined ) return next as never
return "Unknown"
}
Но это всё компромиссы конкретного языка, а не декларативного подхода в целом. Ведь можно же было сделать, например, так:
/**
* Placeholder null $mol_view
*/
Placeholder() {
return null as null | $mol_view
}
/**
* name!number?string \Unknown
*/
@ $mol_mem_key
name(id: number, next?: string) {
if ( next !== undefined ) return next
return "Unknown"
}
Что тут ещё сказать?
Фух, покатались на славу. Пришло время остановиться и перевести дух, поразмыслить над смыслом бытия, и двинуться дальше..
В выступлении "Tree - единый AST чтобы править всеми" можно познакомиться с форматом tree. В выступлении "Свой язык с поддержкой sourcemaps за полчаса" с его пайплайном. А в выступлении "$mol - лучшее средство от геморроя" можно найти краткое введение конкретно в язык view.tree.
Заглядывайте в чат "Разработка языков программирования" всё это обсудить. Или даже в чат "$mol: Разработка" если заинтересовал фреймворк $mol.
Ну и, конечно, предлагайте в комментариях свои идеи как упростить жизнь разработчика интерфейсов, не водружая инвалидные коляски поверх многоэтажных костылей.
Про комменты в jsx надо будет как-то проверить. В каких-то случаях работает двойной слеш, в каких-то фигурные скобки нужны, еще не разобрался) Но добавляются убираются комменты в большенстве случаев без проблем, выделение текста + хоткей
Периодически встречается проблема, когда в jsx куча тегов. Случайно удаляешь/забываешь закрывающий тег, или слеш в нем или что-нибудь подобное. Сложно найти проблемное место
Периодически встречается проблема, когда в jsx куча тегов. Случайно удаляешь/забываешь закрывающий тег, или слеш в нем или что-нибудь подобное. Сложно найти проблемное место
А есть какой-то пример кода?
Периодически встречается проблема, когда в jsx куча тегов. Случайно удаляешь/забываешь закрывающий тег, или слеш в нем или что-нибудь подобное. Сложно найти проблемное место
А есть какой-то пример кода?
тут удален закрывающий тег в середине
Шикарный пример. Хотя, найти место ошибки сложно во многом из-за форматирования. Если добавить пустых строк между блоками и использовать 4 пробела вместо 2, то будет более заметно.
Шикарный пример. Хотя, найти место ошибки сложно во многом из-за форматирования. Если добавить пустых строк между блоками и использовать 4 пробела вместо 2, то будет более заметно.
ага