Здравствуйте, меня зовут Дмитрий Карловский, и я.. тот самый чел, который написал реактивную библиотеку $mol_wire. Именно благодаря мне вам есть сейчас чем пугать детей перед сном.
Но просто написать классную библиотеку - слишком мелкая цель. Построить на ней богатый фреймворк с кучей батареек - уже интересней, но всё ещё не достаточно амбициозно. Разработанный мной подход может стать lingua franca в коммуникациях между библиотеками, состояниями браузера, и даже между удалёнными узлами.
Берегите синапсы, сейчас будет настоящий киберпанк..
Реактивный React
ReactJS сейчас самый популярный фреймворк, вопреки множеству архитектурных просчётов. Вот лишь некоторые из них:
Компонент не отслеживает внешние состояния, от которых он зависит, — обновляется он только при изменении локального. Это требует аккуратных подписок/отписок и своевременных уведомлений об изменениях.
Единственный способ изменить один параметр компонента — это полностью ререндерить внешний компонент, заново сформировав все параметры как для него, так и для соседей. То же касается и добавления/удаления/перемещения компонента.
При перемещении компонента между контейнерами происходит его полное пересоздание. И наоборот, разные экземпляры одного компонента могут быть неуместно реиспользованы.
Создаваемые на лету колбэки приводят к лишним ререндерам, поэтому требуют аккуратной их мемоизации с точным указанием используемых внутри них переменных.
Хуки нельзя применять в условиях, циклах и других местах динамичности потока исполнения, иначе всё сломается.
Ошибки и индикация ожидания происходят вне компонента. Компонент получается не самодостаточным и фатально влияющим и на внешний компонент и, как следствие, на соседей.
Компонент невозможно обновить частично — только полный ререндер. Чтобы это побороть либо обмазываются мемоизацией, либо излишне увеличивают гранулярность компонент.
Отсутствие контроля stateful компонента часто приводит к необходимости разбивать каждый компонент на два: контролируемый stateless и неконтролируемая stateful обёртка над ним. Частичный контроль при этом сопряжён с трудностями и копипастой.
Что ж, давайте вылечим больного, а заодно покажем простоту интеграции реактивной библиотеки $mol_wire в совершенно инородную ему архитектуру.
Начнём издалека — напишем синхронную функцию, которая загружает JSON по ссылке. Для этого напишем асинхронную функцию и конвертируем её в синхронную:
export const getJSON = sync( async function getJSON( uri: string ){
const resp = await fetch(uri)
if( Math.floor( resp.status / 100 ) === 2 ) return resp.json()
throw new Error( `${resp.status} ${resp.statusText}` )
} )
Теперь реализуем API для GitHub, с debounce и кешированием. Поддерживаться у нас будет лишь загрузка данных issue по его номеру:
export class GitHub extends Object {
// cache
@mems static issue( value: number, reload?: "reload" ) {
sleep(500) // debounce
const uri = `https://api.github.com/repos/nin-jin/HabHub/issues/${value}`
return getJSON( uri ) as {
title: string
html_url: string
}
}
}
Сколько бы раз мы ни обращались за данными — результат будет возвращаться из кеша, но если нам потребуется всё же перезагрузить данные — можно передать дополнительный параметр, чтобы запустилась задача по обновлению кеша. В любом случае запрос пойдёт не сразу, а с задержкой в пол секунды.
Теперь, наконец, мы переходим к созданию компонент. Вопреки популярному тренду, мы не будем эмулировать объекты, через грязные функции с хуками, а будем использовать классовые компоненты. А чтобы не повторять одну и ту же логику, создадим базовый класс для наших компонент:
export abstract class Component<
Props = { id: string },
State = {},
SnapShot = any
> extends React.Component<
Partial<Props> & { id: string },
State,
SnapShot
> {
// every component should have guid
id!: string;
// show id in debugger
[Symbol.toStringTag] = this.props.id
// override fields by props to configure
constructor(props: Props & { id: string }) {
super(props)
Object.assign(this, props)
}
// composes inner components as vdom
abstract compose(): any
// memoized render which notify react on recalc
@mem render() {
log("render", "#" + this.id)
Promise.resolve().then(() => this.forceUpdate())
return this.compose()
}
}
Основная идея тут в том, чтобы каждый компонент был полностью самодостаточным, но при этом контролируемым — любое его публичное поле можно переопределить через пропсы. Все пропсы опциональны, кроме идентификатора, который мы требуем задавать извне, чтобы он был глобально уникальным и семантичным.
Важно отметить, что пропсы не отслеживаются реактивной системой — это позволяет передавать в них колбэки и это не будет вызывать ререндеров. Идея тут в том, чтобы разделить инициализацию (через проталкивание пропсов) и собственно работу (путём затягивания через колбэки, предоставленные в пропсах).
Инициализация происходит при конструировании класса, а динамическая работа — когда фреймворк вызывает render. ReactJS славится тем, что вызывает его слишком часто. Тут же, благодаря мемоизации, мы перехватываем у фреймворка контроль за тем, когда фактически будут происходить ререндеры. Когда поменяется любая зависимость от которой зависит результат рендеринга, реактивная система перевычислит его и уведомит фреймворк о необходимости реконцилиации, тогда фреймворк вызовет render и получит свежий VDOM. В остальных же случаях он будет получать VDOM из кеша и ничего дальше не делать.
Такая схема работы уже не позволит использовать в своей логике хуки, но с $mol_wire, хуки — как собаке пятая нога.
Проще понять принцип работы на конкретных примерах, так что давайте создадим простой компонент — поле текстового ввода:
export class InputString extends Component<InputString> {
// statefull!
@mem value( next = "" ) {
return next;
}
change( event: ChangeEvent<HTMLInputElement> ) {
this.value( event.target.value )
this.forceUpdate() // prevent caret jumping
}
compose() {
return (
<input
id={ this.id }
className="inputString"
value={ this.value() }
onInput={ action(this).change }
/>
)
}
}
Тут мы объявили состояние, в котором по умолчанию храним введённый текст, и экшен вызывающийся при вводе для обновления этого состояния. В конце экшена мы заставляем ReactJS немедленно подхватить наши изменения, иначе каретка улетит в конец поля ввода. В остальных случаях в этом нет необходимости. Ну а при передаче экшена в VDOM мы завернули его в обёртку, которая просто превращает синхронный метод в асинхронный.
Теперь давайте воспользуемся этим компонентом в поле ввода числа, в который и поднимем состояние поля ввода текста:
export class InputNumber extends Component<InputNumber> {
// self state
@mem numb( next = 0 ) {
return next;
}
dec() {
this.numb(this.numb() - 1);
}
inc() {
this.numb(this.numb() + 1);
}
// lifted string state as delegate to number state!
@mem str( str?: string ) {
const next = str?.valueOf && Number(str)
if( Object.is( next, NaN ) ) return str ?? ""
const res = this.numb( next )
if( next === res ) return str ?? String( res ?? "" )
return String( res ?? "" )
}
compose() {
return (
<div
id={this.id}
className="inputNumber"
>
<Button
id={ `${this.id}-decrease` }
action={ ()=> this.dec() }
title={ ()=> "➖" }
/>
<InputString
id={ `${this.id}-input` }
value={ next => this.str( next ) } // hack to lift state up
/>
<Button
id={ `${this.id}-increase` }
action={ ()=> this.inc() }
title={ ()=> "➕" }
/>
</div>
)
}
}
Обратите внимание, что мы переопределили у поля ввода текста свойство value, так что теперь оно будет хранить своё состояние не у себя, а в нашем свойстве str, которое на самом деле является кешированным делегатом уже к свойству numb. Логика его немного замысловатая, чтобы при вводе не валидного числа, мы не теряли пользовательский ввод из‑за замены его на *нормализованное* значение.
Можно заметить, что сформированный нами VDOM не зависит ни от каких реактивных состояний, а значит он вычислится лишь один раз при первом рендере, и больше обновляться не будет. Но не смотря на это, текстовое поле будет корректно реагировать на изменения свойств numb и как следствие str.
Так же тут использованы компоненты Button у которых переопределены методы, вызываемые для получения названия кнопки и для выполнения действия при клике. Но о кнопках позже, а пока воспользуемся всеми нашими наработками, чтобы реализовать продвинутый Counter, который не просто переключает число кнопками, но и грузит данные с сервера:
export class Counter extends Component<Counter> {
@mem numb( value = 48 ) {
return value
}
issue( reload?: "reload" ) {
return GitHub.issue( this.numb(), reload )
}
title() {
return this.issue().title;
}
link() {
return this.issue().html_url;
}
compose() {
return (
<div
id={ this.id }
className="counter"
>
<InputNumber
id={ `${this.id}-numb` }
numb={ next => this.numb( next ) } // hack to lift state up
/>
<Safe
id={ `${this.id}-output-safe` }
task={ () => (
<a
id={ `${this.id}-link` }
className="counter-link"
href={ this.link() }
>
{ this.title() }
</a>
) }
/>
<Button
id={ `${this.id}-reload` }
action={ () => this.issue("reload") }
title={ () => "Reload" }
/>
</div>
)
}
}
Как не сложно заметить, состояние текстового поля ввода мы подняли ещё выше — теперь оно оперирует номером issue. По этому номеру мы через GitHub API грузим данные и показываем их рядом, завернув в специальный компонент Safe, задача которого обрабатывать исключительные ситуации в переданном ему коде: при ожидании показывать соответствующий индикатор, а при ошибке — текст ошибки. Реализуется он просто — обычным try-catch:
export abstract class Safe extends Component<Safe> {
task() {}
compose() {
try {
return this.task()
} catch( error ) {
if( error instanceof Promise ) return (
<span
id={ `${this.id}-wait` }
className="safe-wait"
>
?
</span>
)
if( error instanceof Error ) return (
<span
id={ `${this.id}-error` }
className="safe-error"
>
{error.message}
</span>
)
throw error
}
}
}
Наконец, реализуем кнопку, но не простую, а умную, умеющую отображать статус выполняемой задачи:
export class Button extends Component<Button> {
title() {
return ""
}
action( event?: MouseEvent<HTMLButtonElement> ) {}
@mem click( next?: MouseEvent<HTMLButtonElement> | null ) {
if( next ) this.forceUpdate()
return next;
}
@mem status() {
const event = this.click()
if( !event ) return
this.action( event )
this.click( null )
}
compose() {
return (
<button
id={this.id}
className="button"
onClick={ action(this).click }
>
{ this.title() } {" "}
<Safe
id={ `${this.id}-safe` }
task={ () => this.status() }
/>
</button>
)
}
}
Тут мы место того, чтобы сразу запускать действие, кладём событие в реактивное свойство click, от которого зависит свойство status, которое уже и занимается запуском обработчика события. А чтобы обработчик был вызван сразу, а не в следующем фрейме анимации (что важно для некоторых JS API типа clipboard), вызывается forceUpdate. Сам status в штатных ситуациях ничего не возвращает, но в случае ожидания или ошибки показывает соответствующие блоки благодаря Safe.
Весь код этого примера можно найти в песочнице:
Там добавлены ещё и логи, чтобы можно было понять что происходит. Например, вот так выглядит первичный рендеринг:
render #counter
render #counter-numb
render #counter-numb-decrease
render #counter-numb-decrease-safe
render #counter-numb-input
render #counter-numb-increase
render #counter-numb-increase-safe
render #counter-title-safe
render #counter-reload
render #counter-reload-safe
fetch GitHub.issue(48)
render #counter-title-safe
render #counter-title-safe
Тут #counter-title-safe рендерился 3 раза так как сперва он показывал ? на debounce, потом на ожидании собственно загрузки данных, а в конце уже показал загруженные данные.
При нажатии Reaload опять же, не рендерится ничего лишнего — меняется лишь индикатор ожидания на кнопке, так как данные в итоге не поменялись:
render #counter-reload-safe
fetch GitHub.issue(48)
render #counter-reload-safe
render #counter-reload-safe
Ну а при быстром изменении номера — обновляется поле ввода текста и вывод зависящего от него заголовка:
render #counter-numb-input
render #counter-title-safe
render #counter-numb-input
render #counter-title-safe
fetch GitHub.issue(4)
render #counter-title-safe
render #counter-title-safe
Итого, какие проблемы мы решили:
✅ Компонент автоматически точечно (а не как с Redux) отслеживает внешние состояния.
✅ Параметры компонента обновляются без ререндера родителя.
❌ Перемещением компонент по прежнему управляет ReactJS.
✅ Изменение колбэка не приводит к ререндеру.
✅ Наш аналог хуков можно применять в любом месте кода, даже в циклах и условиях.
❌ Обработка ошибок по прежнему управляется ReactJS, поэтому требует ручной работы.
✅ Для частичного обновения можно создать компонент принимающий замыкание.
✅ stateful компоненты полснотью контролируемы.
Можете доработать этот пример и оформить в виде библиотеки типа remol, если готовы заниматься её поддержкой. Или реализовать подобную интеграцию для любого другого фреймворка. А мы пока отстыковываем первую ступень и летим ещё выше..
Реактивный JSX
Не сложно заметить, что отбирая у ReactJS контроль за состоянием, мы фактически низвергаем его с пьедестала фреймворка до уровня библиотеки рендеринга DOM, которой он изначально и являлся. Но это получается очень тяжёлая библиотека рендеринга, делающая слишком много лишней работы и тратящая впустую много памяти.
Давайте возьмём голый строго типизированный JSX, и сделаем его реактивным с помощью $mol_wire, получив полную замену ReactJS, но без VirtualDOM, но с точечными обновлениями реального DOM и другими приятными плюшками.
Для этого мы сперва возьмём $mol_jsx, который так же как E4X создаёт реальные DOM узлы, а не виртуальные:
const title = <h1 class="title" dataset={{ slug: 'hello' }}>{ this.title() }</h1>
const text = title.innerText // Hello, World!
const html = title.outerHTML // <h1 class="title" data-slug="hello">Hello, World!</h1>
Опа, нам больше не нужен ref для получения DOM узла из JSX, ведь мы сразу получаем от него DOM дерево.
Если исполнять JSX не просто так, а в контексте документа, то вместо создания новых элементов, будут использоваться уже существующие, на основе их идентификаторов:
<body>
<h1 id="title">...</h1>
</body>
$mol_jsx_attach( document, ()=> (
<h1 id="title" class="header">Wow!</h1>
) )
<body>
<h1 id="title" class="header">Wow!</h1>
</body>
Опа, мы получили ещё и гидратацию, но без разделения на первичный и вторичный рендеринг. Мы просто рендерим, а существующие элементы реиспользуются, если они есть.
Опа, да мы ж получили ещё и корректные перемещения компонентов, вместо их пересоздания в новом месте. Причём уже не в рамках одного родителя, а в рамках всего документа:
<body>
<article id="todo">
<h1 id="task/1">Complete article about $mol_wire</h1>
<article>
<article id="done"></article>
</body>
$mol_jsx_attach( document, ()=> (
<article id="done">
<h1 id="task/1">Complete article about $mol_wire</h1>
<article>
) )
<body>
<article id="todo"></article>
<article id="done">
<h1 id="task/1">Complete article about $mol_wire</h1>
<article>
</body>
Обратите внимание на использование естественных для HTML атрибутов id и class вместо эфемерных key и className.
В качестве тегов можно использовать, разумеется, и шаблоны (stateless функции), и компоненты (stateful классы). Первые просто вызываются с правильным контекстом, а значит безусловно рендерят своё содержимое. А вторые создают экземпляр объекта, делегируют ему управление рендерингом, и сохраняют ссылку на него в полученном DOM узле, чтобы использовать его снова при следующем рендеринге. В рантайме выглядит это как‑то так:
Тут мы видим два компонента, которые в результате рендеринга вернули один и тот же DOM элемент. Получить экземпляры компонент из DOM элемента не сложно:
const input = InputString.of( element )
Итак, давайте создадим простейший компонент - поле ввода текста:
export class InputString extends View {
// statefull!
@mem value( next = "" ) {
return next
}
// event handler
change( event: InputEvent ) {
this.value( ( event.target as HTMLInputElement ).value )
}
// apply state to DOM
render() {
return (
<input
value={ this.value() }
oninput={ action(this).change }
/>
)
}
}
Почти тот же код, что и с ReactJS, но:
Так как сверка при рендеринге происходит с реальным DOM, а не прошлой версией виртуального, то там не нужен костыль с немедленным обновлением виртуального DOM после обработки события, чтобы при вводе каретка не улетала в конец.
События приходят нативные, а не синтетические, что избавляет от кучи неожиданностей.
Классы для стилизации генерируются автоматически на основе идентификаторов и имён компонент.
Нет необходимости руками собирать идентификаторы элементов — семантичные идентификаторы тоже формируются автоматически.
Для корневого элемента идентификатор вообще не нужно указывать — он устанавливается равным идентификатору компонента.
При конфликте идентификаторов кидается исключение, что гарантирует их глобальную уникальность.
Для иллюстрации последних пунктов, давайте рассмотрим более сложный компонент — поле ввода числа:
export class InputNumber extends View {
// self state
@mem numb( next = 0 ) {
return next
}
dec() {
this.numb( this.numb() - 1 )
}
inc() {
this.numb( this.numb() + 1 )
}
// lifted string state as delegate to number state!
@mem str(str?: string) {
const next = str?.valueOf && Number( str )
if( Object.is( next, NaN ) ) return str ?? ""
const res = this.numb(next)
if( next === res ) return str ?? String( res ?? "" )
return String( res ?? "" )
}
render() {
return (
<div>
<Button
id="decrease"
action={ () => this.dec() }
title={ () => "➖" }
/>
<InputString
id="input"
value={ next => this.str( next ) } // hack to lift state up
/>
<Button
id="increase"
action={ () => this.inc() }
title={ () => "➕" }
/>
</div>
)
}
}
По сгенерированным классам легко навешивать стили на любые элементы:
/** bem-block */
.InputNumber {
border-radius: 0.25rem;
box-shadow: 0 0 0 1px gray;
display: flex;
overflow: hidden;
}
/** bem-element */
.InputNumber_input {
flex: 1 0 auto;
}
/** bem-element of bem-element */
.Counter_numb_input {
color: red;
}
К сожалению, реализовать полноценный CSS‑in‑TS в JSX не представляется возможным, но даже только лишь автогенерация классов уже существенно упрощает стилизацию.
Чтобы всё это работало, надо реализовать лишь базовый класс для реактивных JSX компонент:
/** Reactive JSX component */
abstract class View extends $mol_object2 {
/** Returns component instance for DOM node. */
static of< This extends typeof $mol_jsx_view >( this: This, node: Element ) {
return node[ this as any ] as InstanceType< This >
}
// Allow overriding of all fields via attributes
attributes!: Partial< Pick< this, Exclude< keyof this, 'valueOf' > > >
/** Document to reuse DOM elements by ID */
ownerDocument!: typeof $mol_jsx_document
/** Autogenerated class names */
className = ''
/** Children to render inside */
@ $mol_wire_field
get childNodes() {
return [] as Array< Node | string >
}
/** Memoized render in right context */
@ $mol_wire_solo
valueOf() {
const prefix = $mol_jsx_prefix
const booked = $mol_jsx_booked
const crumbs = $mol_jsx_crumbs
const document = $mol_jsx_document
try {
$mol_jsx_prefix = this[ Symbol.toStringTag ]
$mol_jsx_booked = new Set
$mol_jsx_crumbs = this.className
$mol_jsx_document = this.ownerDocument
return this.render()
} finally {
$mol_jsx_prefix = prefix
$mol_jsx_booked = booked
$mol_jsx_crumbs = crumbs
$mol_jsx_document = document
}
}
/** Returns actual DOM tree */
abstract render(): HTMLElement
}
Наконец, закончив с приготовлениями, напишем уже наше приложение:
export class Counter extends View {
@mem numb( value = 48 ) {
return value
}
issue( reload?: "reload" ) {
return GitHub.issue( this.numb(), reload )
}
title() {
return this.issue().title
}
link() {
return this.issue().html_url
}
render() {
return (
<div>
<InputNumber
id="numb"
numb={ next => this.numb(next) } // hack to lift state up
/>
<Safe
id="titleSafe"
task={ ()=> (
<a id="title" href={ this.link() }>
{ this.title() }
</a>
) }
/>
<Button
id="reload"
action={ ()=> this.issue("reload") }
title={ ()=> "Reload" }
/>
</div>
)
}
}
Весь код этого примера можно найти в песочнице. Вот так вот за 1 вечер мы реализовали свой ReactJS на $mol, добавив кучу уникальных фичей, но уменьшив объём бандла в 5 раз. По скорости же мы идём ноздря в ноздрю с оригиналом:
А как насчёт обратной задачи — написать аналог фреймворка $mol на ReactJS? Вам потребуется минимум 3 миллиона долларов, команда из десятка человек и несколько лет ожидания. Но мы не будем ждать, а отстыкуем и эту ступень..
Реактивный DOM
Раньше DOM был медленным и не удобным. Чтобы с этим совладать были придуманы разные шаблонизаторы и техники VirtualDOM, IncrementalDOM, ShadowDOM. Однако, фундаментальные проблемы RealDOM никуда не деваются:
1. Жадность. Браузер не может в любое время спросить прикладной код «хочу отрендерить эту часть страницы, сгенерируй мне элементов с середины пятого до конца седьмого». Нам приходится сначала сгенерировать огромный DOM, чтобы браузер показал лишь малую его часть. А это крайне ресурсоёмко.
2. Безучастность. Состояние DOM логически зависит как от прикладных состояний, так и от состояний самого DOM. Но браузер не понимает этих зависимостей, не может их гарантировать, и не может оптимизировать обновление DOM.
3. Тернистость. На самом деле DOM нам и не нужен. Нам нужен способ сказать браузеру как и когда рендерить наши компоненты.
Ну да ладно, давайте представим, что было бы, если бы DOM и весь остальной рантайм были реактивными. Мы могли бы безо всяких библиотек связать любые состояния через простые инварианты и браузер бы гарантировал их выполнения максимально оптимальным способом!
Я набросал небольшой пропозал, как это могло бы выглядеть. Для примера, давайте возьмём и привяжем текст параграфа к значению поля ввода:
<input id="input" />
<p id="output"></p>
<script>
const input = document.getElementById('input')
const output = document.getElementById('output')
Object.defineProperty( output, 'innerText', {
get: ()=> 'Hello ' + input.value
} )
</script>
И всё, никаких библиотек, никаких обработчиков событий, никаких DOM-манипуляций. Только наши желания в чистом виде.
А хотите попробовать ReactiveDOM в деле уже сейчас? Я опубликовал прототип полифила $mol_wire_dom. Он не очень эффективен, много чего не поддерживает, но для демонстрации сойдёт:
<div id="root">
<div id="form">
<input id="nickname" value="Jin" />
<button id="clear">Clear</button>
<label>
<input id="greet" type="checkbox" /> Greet
</label>
</div>
<p id="greeting">...</p>
</div>
import { $mol_wire_dom, $mol_wire_patch } from "mol_wire_dom";
// Make DOM reactive
$mol_wire_dom(document.body);
// Make globals reactive
$mol_wire_patch(globalThis);
// Take references to elements
const root = document.getElementById("root") as HTMLDivElement;
const form = document.getElementById("form") as HTMLDivElement;
const nickname = document.getElementById("nickname") as HTMLInputElement;
const greet = document.getElementById("greet") as HTMLInputElement;
const greeting = document.getElementById("greeting") as HTMLParagraphElement;
const clear = document.getElementById("clear") as HTMLButtonElement;
// Setup invariants
Object.assign(root, {
childNodes: () => (greet.checked ? [form, greeting] : [form]),
style: () => ({
zoom: 1 / devicePixelRatio
})
});
Object.assign(greeting, {
textContent: () => `Hello ${nickname.value}!`
});
// Set up handlers
clear.onclick = () => (nickname.value = "");
Тут мы применили ещё и $mol_wire_patch чтобы сделать глобальные свойства реактивными. Поэтому при изменении зума браузера размер интерфейса будет меняться так, чтобы это компенсировать. При нажатии на кнопку введённое в поле имя будет очищаться. А отображаться текущее имя будет в приветствии, которое показывается только, когда чекбокс взведён.
Ленивый DOM
А теперь представьте, как было бы классно, если бы браузеры поддержали всё это, да без полифилов. Мы могли бы писать легко поддерживаемые веб приложения даже без фреймворков. А с фреймворком могло бы быть и ещё лаконичней, но всё ещё легковесно.
Вы только гляньте, как фреймворк, построенный на $mol_wire, просто уничтожает как низкоуровневых конкурентов, так даже и VanillaJS:
И дело тут не в том, что он так быстро рендерит DOM, а как раз наоборот, в том, что он не рендерит DOM, когда он вне видимой области, даже если это сложная вёрстка, а не плоский список с фиксированной высотой строк.
А представьте как ускорился бы web, если сами браузеры научились бы так делать — запрашивать у прикладного кода ровно то, что необходимо для отображения, и самостоятельно следить за зависимостями.
Когда я показываю подобные картинки, меня часто обвиняют в нечестности, ведь к другим фреймворкам тоже можно прикрутить virtual‑scroll и будет быстро. Или предлагают отключить виртуальный рендеринг, чтобы уравнять реализации по самому низкому уровню. Это всё равно что делать лоботомию Каспарову для уравнения шансов, так как он слишком хорошо играет в шахматы.
Однако, важно понимать разницу между поведением по умолчанию и поведением, требующим долгой и аккуратной реализации, да ещё и с кучей ограничений:
Именно поэтому вы почти не встретите виртуального рендеринга в приложениях на других фреймворках. И именно поэтому вы почти не встретите приложений без виртуализации на $mol.
Грамотная реализация виртуального рендеринга — не самая простая задача, особенно учитывая не оптимизированную для этого архитектуру большинства фреймворков. Я подробно рассказывал об этом в докладе:
На мой взгляд только LazyDOM может обеспечить нас отзывчивыми интерфейсами во всё более раздувающихся объёмах данных и во всё более снижающемся уровне подготовки прикладных разработчиков. Потому нам нужно продавить его внедрение в браузеры.
Но, как показывает мой опыт, пропозалы писать бесполезно — их просто игнорируют. Нужно взять на вооружение тактику обещаний: сначала множество библиотек начали их использовать, а потом браузеры втянули их в себя и стандартизовали.
Вот и тут нам, разработчикам, нужно уже начинать внедрять поддержку этого реактивного клея, чтобы различные библиотеки могли хорошо дружить друг с другом, встраиваясь в единую реактивную систему, а не требовать от прикладных программистов постоянного ручного перекладывания данных между разнородными хранилищами.
Если вы разрабатываете библиотеку или фреймворк, и мне удалось убедить вас поддержать общий реактивный API, то свяжитесь со мной, чтобы мы обсудили детали. Интеграция возможна как на уровне интерфейсов путём реализации полностью своих подписчиков и издателей, так и можно взять готовые части $mol_wire, чтобы не париться с велосипедами.
Фреймворк на основе $mol_wire
Наконец, позвольте показать вам, как тот же продвинутый счётчик реализуется на $mol, который я всю статью тизерил..
Для загрузки данных есть стандартный модуль ($mol_fetch). Более того, для работы с GitHub есть стандартный модуль ($mol_github). Так же возьмём стандартные кнопки ($mol_button), стандартные ссылки ($mol_link), стандартные поля ввода текста ($mol_string) и числа ($mol_number), завернём всё в вертикальный список ($mol_list) и вуаля:
$my_counter $mol_list
Issue $mol_github_issue
title => title
web_uri => link
json? => data?
sub /
<= Numb $mol_number
value? <=> numb? 48
<= Title $mol_link
title <= title
uri <= link
<= Reload $mol_button_minor
title @ \Reload
click? <=> reload?
export class $my_counter extends $.$my_counter {
Issue() {
const endpoint = `https://api.github.com/repos`
const uri = `${ endpoint }/nin-jin/HabHub/issues/${ this.numb() }`
return this.$.$mol_github_issue.item( uri )
}
reload() {
this.data( null )
}
}
При даже чуть большей функциональности (например, поддержка цветовых тем, локализации и пр), кода на $mol получилось в 2 раза меньше, чем в варианте с JSX. А главное — уменьшилась когнитивная сложность. Но это уже совсем другая история..
Пока же, приглашаю вас попробовать $mol_wire в своих проектах. А если у вас возникнут сложности, не стесняйтесь задавать вопросы в теме про $mol на форуме Hyper Dev.
