Здравствуйте, меня зовут Дмитрий Карловский и я хочу сыграть с вами в игру. Правила её очень просты, но их нарушение приведёт вас к победе. Почувствуйте себя в роли хакера выбирающегося из JavaScript песочницы с целью прочитать куки, намайнить биткоины, сделать дефейс или ещё что-нибудь интересное.

https://sandbox.js.hyoo.ru/

А далее я расскажу как работает песочница и подкину несколько идей для взлома.

Как это работает

Итак, первым делом нам надо спрятать все глобальные переменные. Сделать это просто достаточно замаскировать их одноимёнными локальными переменными:

for( let name in window ) {    context_default[ name ] = undefined}

Однако, многие свойства (например, window.constructor) являются неитерируеммыми. Поэтому необходимо итерироваться по всем пропертям объекта:

for( let name of Object.getOwnPropertyNames( window ) ) {    context_default[ name ] = undefined}

Но Object.getOwnPropertyNames возвращает лишь собственные свойства объекта, игнорируя всё, что он наследует от прототипа. Поэтому надо аналогичным образом пройтись по всей цепочке прототипов и собрать имена всех возможных свойств глобального объекта:

function clean( obj : object ) {    for( let name of Object.getOwnPropertyNames( obj ) ) {        context_default[ name ] = undefined    }    const proto = Object.getPrototypeOf( obj )    if( proto ) clean( proto )}clean( win )

И всё бы хорошо, да только этот код падает, ибо в строгом режиме нельзя объявлять локальную переменную с именем eval:

'use strict'var eval // SyntaxError: Unexpected eval or arguments in strict mode

А вот использовать пожалуйста:

'use strict'eval('document.cookie') // password=P@zzW0rd

Ну, ничего, благо глобальный eval можно просто удалить:

'use strict'delete window.evaleval('document.cookie') // ReferenceError: eval is not defined

А для надёжности лучше пройтись по всем собственным свойствам и всё поудалять:

for( const key of Object.getOwnPropertyNames( window ) ) delete window[ key ]

Зачем нам вообще строгий режим? Да потому что без него можно использовать arguments.callee.caller чтобы получить любую функцию выше по стеку и натворить дел:

function unsafe(){ console.log( arguments.callee.caller ) }function safe(){ unsafe() }safe() //  safe(){ unsafe() }

Кроме того, в нестрогом режиме легко получить глобальный неймспейс просто взяв this при вызове функции не как метода:

function get_global() { return this }get_global() // window

Ладно, все глобальные переменные мы замаскировали. Но их значения всё ещё можно получить из примитивов языка. Например:

var Function = ( ()=>{} ).constructorvar hack = new Function( 'return document.cookie' )hack() // password=P@zzW0rd

Что делать? Удаляем небезопасные конструкторы:

Object.defineProperty( Function.prototype , 'constructor' , { value : undefined } )

Этого было бы достаточно для какого-то древнего яваскрипта, но сейчас у нас есть разные виды функций и каждый вариант следует обезопасить:

var Function = Function || ( function() {} ).constructorvar AsyncFunction = AsyncFunction || ( async function() {} ).constructorvar GeneratorFunction = GeneratorFunction || ( function*() {} ).constructor

В одной песочнице могут запускаться разные скрипты и будет не хорошо, если они смогут влиять на работоспособность друг друга, поэтому замораживаем все объекты, доступные через примитивы языка:

for( const Class of [    String , Number , BigInt , Boolean , Array , Object , Promise , Symbol , RegExp ,     Error , RangeError , ReferenceError , SyntaxError , TypeError ,    Function , AsyncFunction , GeneratorFunction ,] ) {    Object.freeze( Class )    Object.freeze( Class.prototype )}

Ок, тотальное огораживание мы реализовали, но цена этому жёсткое надругательство над рантаймом, что может сломать и наше собственное приложение. То есть нам нужен отдельный рантайм для песочницы, где можно творить любые непотребства. Получить его можно двумя способами: через скрытый фрейм или через веб-воркер.

Особенности воркера:

• Полная изоляция памяти. Из воркера невозможно сломать рантайм основного приложения.
• В воркер нельзя передать свои функции, что часто необходимо. Это ограничение можно частично обойти через реализацию RPC.
• Воркер можно прибить по таймауту, если злодей напишет там бесконечный цикл.
• Вся коммуникация строго асинхронная, что не очень быстро.

Особенности фрейма:

• Можно передавать во фрейм любые объекты и функции, но по ссылкам можно случайно предоставить доступ к тому, к чему не стоило бы.
• Бесконечный цикл в песочнице вешает всё приложение.
• Вся коммуникация строго синхронная.

Реализация RPC для воркера дело не хитрое, но его ограничения не всегда приемлемы. Поэтому рассмотрим вариант с фреймом.

Если в песочницу передать какой-либо объект из которого по ссылкам доступен хоть какой-то изменяемый объект, то из песочницы можно будет его поменять и сломать наше приложение:

numbers.toString = ()=> { throw 'lol' }

Но это ещё цветочки. Передача в во фрейм любой функции тут же откроет кулхацкеру настеж все двери:

var Function = random.constructorvar hack = new Function( 'return document.cookie' )hack() // password=P@zzW0rd

Ну ничего, прокси спешит на помощь:

const safe_derived = ( val : any ) : any => {    const proxy = new Proxy( val , {        get( val , field : any ) {            return safe_value( val[field] )        },        set() { return false },        defineProperty() { return false },        deleteProperty() { return false },        preventExtensions() { return false },        apply( val , host , args ) {            return safe_value( val.call( host , ... args ) )        },        construct( val , args ) {            return safe_value( new val( ... args ) )        },    }    return proxy})

То есть мы разрешаем обращаться к свойствам, вызывать функции и конструировать объекты, но запрещаем все инвазивные операции. Соблазнительно возвращаемые значения тоже заворачивать в такие прокси, но тогда можно будет добраться по ссылкам до объекта у которого есть какой-либо мутирующий метод и воспользоваться им:

config.__proto__.__defineGetter__( 'toString' , ()=> ()=> 'rofl' )({}).toString() // rofl

Поэтому все значения принудительно прогоняем через промежуточную сериализацию в JSON:

const SafeJSON = frame.contentWindow.JSONconst safe_value = ( val : any ) : any => {    const str = JSON.stringify( val )    if( !str ) return str    val = SafeJSON.parse( str )    return val}

Таким образом из песочницы будут доступны только объекты и функции которые мы передали туда явно. Но порой нужно и неявно передавать некоторые объекты. Для них заведём whitelist в который будем автоматически добавлять все объекты, что заворачиваются в безопасный прокси, проходят обезвреживание или приходят из песочницы:

const whitelist = new WeakSetconst safe_derived = ( val : any ) : any => {    const proxy = ...    whitelist.add( proxy )    return proxy}const safe_value = ( val : any ) : any => {    if( whitelist.has( val ) ) return val    const str = JSON.stringify( val )    if( !str ) return str    val = SafeJSON.parse( str )    whitelist.add( val )    return val}

И на случай, если разработчик по невнимательности предоставит доступ к какой-либо функции позволяющей интерпретировать строку как код, заведём ещё blacklist, с перечислением того, что в песочницу нельзя передавать ни при каких обстоятельствах:

const blacklist = new Set([    ( function() {} ).constructor ,    ( async function() {} ).constructor ,    ( function*() {} ).constructor ,    eval ,    setTimeout ,    setInterval ,])

В результате у нас получилась довольно безопасная песочница со следующими характеристиками:

• Можно исполнять произвольный JS код.
• Код исполняется синхронно и не требует делать все функции выше по стеку асинхронными.
• Нельзя прочитать данные к которым не предоставлен доступ.
• Нельзя изменить поведение использующего песочницу приложения.
• Нельзя сломать работоспособность собственно песочницы.
• Можно подвесить приложение бесконечным циклом.

Если есть идеи как это можно улучшить или хотите вступить в ТехноГильдию пишите телеграммы.

Ссылочки

• https://sandbox.js.hyoo.ru/ онлайн песочница с примерами потенциально опасного кода.
• https://calc.hyoo.ru/ электронная таблица, позволяющая использовать в ячейках произвольный JS код.
• https://t.me/mol_news канал с новостями об экосистеме $mol и открытых проектах ТехноГильдии.

Здравствуйте, меня зовут Дмитрий Карловский и я не прощаю ошибок. Как только вижу оную тут же бросаю что-нибудь исключительно тяжёлое. И как же тяжела работа программиста на JS...

class Foo extends Object {}const foo = new Foo`Здравствуйте, ${ foo }!`// "Здравствуйте [object Object]!"`В этом месяце вы заработали ${ foo / 1000 } тысяч рублей.`// "В этом месяце вы заработали NaN тысяч рублей."`Ваша цель "${ 'foo'[4] }" наконец-то достигнута.`// "Ваша цель "undefined" наконец-то достигнута."`Осталось ещё ${ foo.length - 1 } целей и вы достигните успеха.`// "Осталось ещё NaN целей и вы достигните успеха."

Облегчить его страдания можно разными путями..

1. Прикрыться тайпскриптом. Но в рантайме ноги всё равно остаются босыми, и на них кто-нибудь вечно наступает.
2. Обложиться проверками. Но чуть замешкаешься и рантайм грабли тут же бьют по голове.
3. Исправить JS. Даже не надейтесь.
4. Исправить JS рантайм. Ну, давайте подумаем..

Проблемы с динамической типизацией JS возникают по 2 основным причинам:

• Автоматическое (и порой неуместное) приведение типов, когда значение одного типа используется в контексте, предназначенном для другого.
• Возврат undefined в качестве значения не объявленных полей.

Сначала разберёмся с первой проблемой. JS устроен так, что приведение примитивных типов мы никак исправить не сможем. А вот за приведением объектов у нас есть полный контроль. Поэтому давайте пропатчим глобальный прототип всех объектов, чтобы никакие объекты по умолчанию не допускали приведения типов:

Object.prototype[ Symbol.toPrimitive ] = function() {    throw new TypeError( `Field Symbol(Symbol.toPrimitive) is not defined` )}

Теперь, чтобы разрешить приведение типа, нужно переопределить метод Symbol.toPrimitive у нужного объекта.

Ладно, с первой проблемой разобрались. Но как-то она далась нам подозрительно легко Что-то тут не так! Не похоже это на Веб Ну да ладно, пошли к следующей.

Тут нам нужно как-то перехватывать обращения к произвольным полям объекта, даже если они ещё никак не были объявлены. В JS для этого есть только один механизм прокси. Что ж, напишем такой прокси который при обращении к любому полю громко ругается квазицензурными словами:

export let $mol_strict_object = new Proxy( {}, {    get( obj: object, field: PropertyKey, proxy: object ) {        const name = JSON.stringify( String( field ) )        throw new TypeError( `Field ${ name } is not defined` )    },})

К сожалению, поменять prototype у Object, как мы это сделали ранее, браузер нам уже не даст. Как и поменять прототип у Object.prototype он всегда будет null. Зато мы можем менять прототипы у почти всех остальных стандартных классов унаследованных от Object:

Поэтому пройдёмся по всем глобальным переменным:

for( const name of Reflect.ownKeys( $ ) ) {    // ...}

Отсеим те из них, кто не является классами:

const func = Reflect.getOwnPropertyDescriptor( globalThis, name )!.valueif( typeof func !== 'function' ) continueif(!( 'prototype' in func )) continue

Обратите внимание, что мы не используем globalThis[name] для получения значения, чтобы не триггерить ненужные варнинги.

Теперь оставляем лишь те классы, что непосредственно унаследованы от Object:

const proto = func.prototypeif( Reflect.getPrototypeOf( proto ) !== Object.prototype ) continue

И, наконец, подменяем прототип прототипа с Object.prototype на наш строгий вариант:

Reflect.setPrototypeOf( proto, $mol_strict_object )

Теперь почти все стандартные объекты будут смотреть на вас с укоризной, при обращении к свойству, которому не задано значение. Ведь если значение задано, то браузер не пойдёт по цепочке прототипов и не дойдёт до нашего прокси.

К сожалению, есть и исключения, такие как сам Object, все объектные литералы и всё, что унаследовано от EventTarget, который тоже не дают менять.

И тут CSSStyleDeclaration делает нам подножку: если подменить его прототип на прокси (даже прозрачный, не кидающий исключений), то, внезапно, в Хроме 89 он перестаёт синхронизироваться с атрибутом style dom-элемента:

( <div style={{ color: 'red' }} /> ).outerHTML // <div></div>

Поэтому его пока что приходится вносить в исключения.

Есть и ещё одна беда Если объявлять прикладные классы так:

class Foo {}

То объекты этих классов не будут строгими. Но если объявить их так:

class Foo extends Object {}

То ничего особо не изменится. Но вот если подменить глобальный объект Object на свой строгий подкласс:

globalThis.Object = function $mol_strict_object( this: object, arg: any ) {    let res = Object_orig.call( this, arg )    return this instanceof $mol_strict_object ? this : res}Reflect.setPrototypeOf( Object, Reflect.getPrototypeOf({}) )Reflect.setPrototypeOf( Object.prototype, $mol_strict_object )

То прикладные классы, явно унаследованные от Object, станут строгими.

Итак, что у нас получилось...

class Foo extends Object {}const foo = new Foo`Здравствуйте, ${ foo }!`// TypeError: Field "Symbol(Symbol.toPrimitive)" is not defined`В этом месяце вы заработали ${ foo / 1000 } тысяч рублей.`// TypeError: Field "Symbol(Symbol.toPrimitive)" is not defined`Ваша цель "${ 'foo'[4] }" наконец-то достигнута.`// TypeError: Field "4" is not defined`Осталось ещё ${ foo.length - 1 } целей и вы достигните успеха.`// TypeError: Field "length" is not defined

На случай, если это будут читать дети, подчеркну:

Не меняйте поведение рантайма в библиотеках, ибо таким образом вы можете сломать кому-нибудь приложение. А вот для запуска тестов лучше использовать как раз максимально строгий рантайм мало ли использовать вашу библиотеку будут именно в нём.

Если хотите лучше понять как всё это работает, то гляньте эту статью: Насколько JavaScript сильный?.

Полные исходники можно найти тут: $mol_strict.

Для подключения к своему NPM проекту достаточно прописать где-нибудь в начале точки входа:

import "mol_strict"

Или:

require("mol_strict")

Другие независимые сборки микробиблиотек из $mol можно найти тут: $mol: Usage from NPM ecosystem.

А если хотите обсудить подноготную JS рантайма, то присоединяйтесь к этим чатам:

• У браузера под юбкой (Обсуждаем разработку браузерных движков. Парсинг, рендеринг, архитектура, вот это всё.)
• UfoStation Chat (ФП Фронтенд и Программирование.)

Наконец, в твиттере _jinnin можно обнаружить много свежих мыслей на тему фронтенда, JS, UX и прочей дичи.

Здравствуйте, меня зовут Дмитрий Карловский и раньше я тоже использовал Perl для разработки фронтенда. Только гляньте, каким лаконичным кодом можно распарсить, например, имейл:

/^(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,})|("(?:((?:(?:([\u{1}-\u{8}\u{b}\u{c}\u{e}-\u{1f}\u{21}\u{23}-\u{5b}\u{5d}-\u{7f}])|(\\[\u{1}-\u{9}\u{b}\u{c}\u{e}-\u{7f}]))){0,}))"))@(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,}))$/gsu

Тут, правда, закралось несколько ошибок. Ну ничего, пофиксим в следующем релизе!

Шутки в сторону

По мере роста, регулярки очень быстро теряют свою понятность. Не зря в интернете есть десятки сервисов для отладки регулярок. Вот лишь некоторые из них:

• https://regex101.com/
• https://regexr.com/
• https://www.debuggex.com/
• https://extendsclass.com/regex-tester.html

А с внедрением новых фичей, они теряют и лаконичность:

/(?<слово>(?<буквица>\p{Script=Cyrillic})\p{Script=Cyrillic}+)/gimsu

У регулярок довольно развесистых синтаксис, который то и дело выветривается из памяти, что требует постоянное подсматривание в шпаргалку. Чего только стоят 5 разных способов экранирования:

/\t//\ci//\x09//\u0009//\u{9}/u

В JS у нас есть интерполяция строк, но как быть с регулярками?

const text = 'lol;)'// SyntaxError: Invalid regular expression: /^(lol;)){2}$/: Unmatched ')'const regexp = new RegExp( `^(${ text }){2}$` )

Ну, или у нас есть несколько простых регулярок, и мы хотим собрать из них одну сложную:

const VISA = /(?<type>4)\d{12}(?:\d{3})?/const MasterCard = /(?<type>5)[12345]\d{14}/// Invalid regular expression: /(?<type>4)\d{12}(?:\d{3})?|(?<type>5)[12345]\d{14}/: Duplicate capture group nameconst CardNumber = new RegExp( VISA.source + '|' + MasterCard.source )

Короче, писать их сложно, читать невозможно, а рефакторить вообще адски! Какие есть альтернативы?

Свои регулярки с распутным синтаксисом

Полностью своя реализация регулярок на JS. Для примера возьмём XRegExp:

• API совместимо с нативным.
• Можно форматировать пробелами.
• Можно оставлять комментарии.
• Можно расширять своими плагинами.
• Нет статической типизации.
• Отсутствует поддержка IDE.
• 

В общем, всё те же проблемы, что и у нативных регулярок, но втридорога.

Генераторы парсеров

Вы скармливаете им грамматику на специальном DSL, а они выдают вам JS код функции парсинга. Для примера возьмём PEG.js:

• Наглядный синтаксис.
• Каждая грамматика вещь в себе и не компонуется с другими.
• Нет статической типизации генерируемого парсера.
• Отсутствует поддержка IDE.
• Минимум 2 кб в ужатопережатом виде на каждую грамматику.

Пример в песочнице.

Это решение более мощное, но со своими косяками. И по воробьям из этой пушки стрелять не будешь.

Билдеры нативных регулярок

Для примера возьмём TypeScript библиотеку $mol_regexp:

• Строгая статическая типизация.
• Хорошая интеграция с IDE.
• Композиция регулярок с именованными группами захвата.
• Поддержка генерации строки, которая матчится на регулярку.
• 

Это куда более легковесное решение. Давайте попробуем сделать что-то не бесполезное..

Номера банковских карт

Импортируем компоненты билдера

Это либо функции-фабрики регулярок, либо сами регулярки.

const {    char_only, latin_only, decimal_only,    begin, tab, line_end, end,    repeat, repeat_greedy, from,} = $mol_regexp

Ну или так, если вы ещё используете NPM

import { $mol_regexp: {    char_only, decimal_only,    begin, tab, line_end,    repeat, from,} } from 'mol_regexp'

Пишем регулярки для разных типов карт

// /4(?:\d){12,}?(?:(?:\d){3,}?){0,1}/gsuconst VISA = from([    '4',    repeat( decimal_only, 12 ),    [ repeat( decimal_only, 3 ) ],])// /5[12345](?:\d){14,}?/gsuconst MasterCard = from([    '5',    char_only( '12345' ),    repeat( decimal_only, 14 ),])

В фабрику можно передавать:

• Строку и тогда она будет заэкранирована.
• Число и оно будет интерпретировано как юникод кодепоинт.
• Другую регулярку и она будет вставлена как есть.
• Массив и он будет трактован как последовательность выражений. Вложенный массив уже используется для указания на опциональность вложенной последовательности.
• Объект означающий захват одного из вариантов с именем соответствующим полю объекта (далее будет пример).

Компонуем в одну регулярку

// /(?:(4(?:\d){12,}?(?:(?:\d){3,}?){0,1})|(5[12345](?:\d){14,}?))/gsuconst CardNumber = from({ VISA, MasterCard })

Строка списка карт

// /^(?:\t){0,}?(?:((?:(4(?:\d){12,}?(?:(?:\d){3,}?){0,1})|(5[12345](?:\d){14,}?))))(?:((?:\r){0,1}\n)|(\r))/gmsuconst CardRow = from(    [ begin, repeat( tab ), {CardNumber}, line_end ],    { multiline: true },)

Сам список карточек

const cards = `    3123456789012    4123456789012    551234567890123    5512345678901234`

Парсим текст регуляркой

for( const token of cards.matchAll( CardRow ) ) {    if( !token.groups ) {        if( !token[0].trim() ) continue        console.log( 'Ошибка номера', token[0].trim() )        continue    }    const type = ''        || token.groups.VISA && 'Карта VISA'        || token.groups.MasterCard && 'MasterCard'    console.log( type, token.groups.CardNumber )}

Тут, правда, есть небольшое отличие от нативного поведения. matchAll с нативными регулярками выдаёт токен лишь для совпавших подстрок, игнорируя весь текст между ними. $mol_regexp же для текста между совпавшими подстроками выдаёт специальный токен. Отличить его можно по отсутствию поля groups. Эта вольность позволяет не просто искать подстроки, а полноценно разбивать весь текст на токены, как во взрослых парсерах.

Результат парсинга

Ошибка номера 3123456789012Карта VISA 4123456789012Ошибка номера 551234567890123MasterCard 5512345678901234

Заценить в песочнице.

E-Mail

Регулярку из начала статьи можно собрать так:

const {    begin, end,    char_only, char_range,    latin_only, slash_back,    repeat_greedy, from,} = $mol_regexp// Логин в виде пути разделённом точкамиconst atom_char = char_only( latin_only, "!#$%&'*+/=?^`{|}~-" )const atom = repeat_greedy( atom_char, 1 )const dot_atom = from([ atom, repeat_greedy([ '.', atom ]) ])// Допустимые символы в закавыченном имени сендбоксаconst name_letter = char_only(    char_range( 0x01, 0x08 ),    0x0b, 0x0c,    char_range( 0x0e, 0x1f ),    0x21,    char_range( 0x23, 0x5b ),    char_range( 0x5d, 0x7f ),)// Экранированные последовательности в имени сендбоксаconst quoted_pair = from([    slash_back,    char_only(        char_range( 0x01, 0x09 ),        0x0b, 0x0c,        char_range( 0x0e, 0x7f ),    )])// Закавыченное имя сендборксаconst name = repeat_greedy({ name_letter, quoted_pair })const quoted_name = from([ '"', {name}, '"' ])// Основные части имейла: доменная и локальнаяconst local_part = from({ dot_atom, quoted_name })const domain = dot_atom// Матчится, если вся строка является имейломconst mail = from([ begin, local_part, '@', {domain}, end ])

Но просто распарсить имейл эка невидаль. Давайте сгенерируем имейл!

//  SyntaxError: Wrong param: dot_atom=foo..barmail.generate({    dot_atom: 'foo..bar',    domain: 'example.org',})

Упс, ерунду сморозил Поправить можно так:

// foo.bar@example.orgmail.generate({    dot_atom: 'foo.bar',    domain: 'example.org',})

Или так:

// "foo..bar"@example.orgmail.generate({    name: 'foo..bar',    domain: 'example.org',})

Погонять в песочнице.

Роуты

Представим, что сеошник поймал вас в тёмном переулке и заставил сделать ему "человекопонятные" урлы вида /snjat-dvushku/s-remontom/v-vihino. Не делайте резких движений, а медленно соберите ему регулярку:

const translit = char_only( latin_only, '-' )const place = repeat_greedy( translit )const action = from({ rent: 'snjat', buy: 'kupit' })const repaired = from( 's-remontom' )const rooms = from({    one_room: 'odnushku',    two_room: 'dvushku',    any_room: 'kvartiru',})const route = from([    begin,    '/', {action}, '-', {rooms},    [ '/', {repaired} ],    [ '/v-', {place} ],    end,])

Теперь подсуньте в неё урл и получите структурированную информацию:

// `/snjat-dvushku/v-vihino`.matchAll(route).next().value.groups{    action: "snjat",    rent: "snjat",    buy: "",    rooms: "dvushku",    one_room: "",    two_room: "dvushku",    any_room: "",    repaired: "",    place: "vihino",}

А когда потребуется сгенерировать новый урл, то просто задайте группам нужные значения:

// /kupit-kvartiru/v-moskveroute.generate({    buy: true,    any_room: true,    repaired: false,    place: 'moskve',})

Если задать true, то значение будет взято из самой регулярки. А если false, то будет скипнуто вместе со всем опциональным блоком.

И пока сеошник радостно потирает руки предвкушая первое место в выдаче, незаметно достаньте телефон, вызовите полицию, а сами скройтесь в песочнице.

Как это работает?

Нативные именованные группы, как мы выяснили ранее, не компонуются. Попадётся вам 2 регулярки с одинаковыми именами групп и всё, поехали за костылями. Поэтому при генерации регулярки используются анонимные группы. Но в каждую регулярку просовывается массив groups со списком имён:

// time.source == "((\d{2}):(\d{2}))"// time.groups == [ 'time', 'hours', 'minutes' ]const time = from({    time: [        { hours: repeat( decimal_only, 2 ) },        ':',        { minutes: repeat( decimal_only, 2 ) },    ],)

Наследуемся, переопределям exec и добавляем пост-процессинг результата с формированием в нём объекта groups вида:

{    time: '12:34',    hours: '12,    minutes: '34',}

И всё бы хорошо, да только если скомпоновать с нативной регуляркой, содержащей анонимные группы, но не содержащей имён групп, то всё поедет:

// time.source == "((\d{2}):(\d{2}))"// time.groups == [ 'time', 'minutes' ]const time = wrong_from({    time: [        /(\d{2})/,        ':',        { minutes: repeat( decimal_only, 2 ) },    ],)

{    time: '12:34',    hours: '34,    minutes: undefined,}

Чтобы такого не происходило, при композиции с обычной нативной регуляркой, нужно "замерить" сколько в ней объявлено групп и дать им искусственные имена "0", "1" и тд. Сделать это не сложно достаточно поправить регулярку, чтобы она точно совпала с пустой строкой, и посчитать число возвращённых групп:

new RegExp( '|' + regexp.source ).exec('').length - 1

И всё бы хорошо, да только String..match и String..matchAll клали шуруп на наш чудесный exec. Однако, их можно научить уму разуму, переопределив для регулярки методы Symbol.match и Symbol.matchAll. Например:

*[Symbol.matchAll] (str:string) {    const index = this.lastIndex    this.lastIndex = 0    while ( this.lastIndex < str.length ) {        const found = this.exec(str)        if( !found ) break        yield found    }    this.lastIndex = index}

И всё бы хорошо, да только тайпскрипт всё равно не поймёт, какие в регулярке есть именованные группы:

interface RegExpMatchArray {    groups?: {        [key: string]: string    }}

Что ж, активируем режим обезьянки и поправим это недоразумение:

interface String {    match< RE extends RegExp >( regexp: RE ): ReturnType<        RE[ typeof Symbol.match ]    >    matchAll< RE extends RegExp >( regexp: RE ): ReturnType<        RE[ typeof Symbol.matchAll ]    >}

Теперь TypeScript будет брать типы для groups из переданной регулярки, а не использовать какие-то свои захардкоженные.

Ещё из интересного там есть рекурсивное слияние типов групп, но это уже совсем другая история.

Напутствие

• Подробности в документация по $mol_regexp.
• Пример из дикой природы токенайзеры MarkedText: $hyoo_marked.
• Другие микро библиотеки из экосистемы MAM доступные в NPM.
• Если у вас аллергия на $mol, то в этой статье можете найти ещё несколько популярных библиотек для парсинга.

Но что бы вы ни выбрали знайте, что каждый раз, когда вы пишете регулярку вручную, где-то в интернете плачет (от счастья) один верблюд.

Здравствуйте, меня зовут Дмитрий Карловский и я автор одного из первых фреймворков целиком и полностью написанных на тайпскрипте $mol. Он по максимуму использует возможности статической типизации. И сегодня речь пойдёт о максимально жёсткой статической фиксации стилей.

Это расшифровка выступления на PiterJS#46. Вы можете либо посмотреть видео запись, либо открыть в интерфейсе проведения презентаций, либо читать как статью...

Подопытное приложение

Разбирать мы будем весьма простое приложение $my_profile, которое состоит из двух панелей: меню и детализация. А каждая панель состоит из двух частей: заголовка и тела.

Генерация классов

Описывается такое приложение крайне простым кодом..

$my_profile $mol_view sub /    <= Menu $my_panel    <= Details $my_panel$my_panel $mol_view sub /    <= Head $mol_view    <= Body $mol_scroll

Не буду грузить вас этим птичьим языком. Скажу, лишь, что из него генерируется typescript класс следующего вида..

interface $my_profile extends $mol_view {    Menu(): $my_panel    Details(): $my_panel} )interface $my_panel extends $mol_view {    Head(): $mol_view    Body(): $mol_scroll} )

Каждый компонент это некоторый класс, который наследуется от другого компонента. И в нём, для каждого вложенного компонента генерится метод, который возвращает экземпляр соответствующего класа. Такие методы обычно пишутся с большой буквы.

Генерация DOM

Моловский компонент, когда рендерится, генерирует некоторый DOM-элемент. Имя этого элемента по умолчанию совпадает с именем инстанцированного класса компонента, что довольно удобно при обзоре сгенерированного DOM-дерева. При необходимости имя элемента может быть переопределено через свойство dom_name. Кроме того, автоматически генерируется набор атрибутов, предназначенных для подключения стилей. При этом учитывается не только собственное глобальное имя компонента, но и глобальные имена всех его предков, а так же его локальное имя во внешнем компоненте, глобальные имена внешнего компонента и его предков и так далее рекурсивно до корня приложения.

interface $my_profile extends $mol_view {    Menu(): $my_panel    Details(): $my_panel} )interface $my_panel extends $mol_view {    Head(): $mol_view    Body(): $mol_scroll} )

<mol_view    mol_view    my_panel_body    my_profile_details_body    >    <mol_button_major        mol_view        mol_button        mol_button_major        my_profile_signup        >

В данном примере мы видим следующие атрибуты:

mol_view базовый класс для всех моловских компонент, через него можно, например, сделать reset для вообще всех компонент, без риска поломать, не моловские компоненты.
my_panel_body значит это компонент с локальным именем Body внутри внешнего компонента $my_panel.
my_profile_details_body значит тот $my_panel имеет локальное имя Details в приложении $my_profile.

Наложение стилей

Таким образом мы получаем исчерпывающий набор атрибутов для стилизации компонент, без традиционного ручного прописывания классов элементам. И как бы глубоко ни располагался элемент специфичность селектора остаётся постоянной, что очень удобно, когда надо переопределять стили.

<mol_view    mol_view    my_panel_body    my_profile_details_body    >    <mol_button_major        mol_view        mol_button        mol_button_major        my_profile_signup        >

[my_profile_details_body] {    overflow: 'overlay';}[my_profile_details_body] [mol_button] {    border-radius: .5rem;}

Но у такого написания CSS есть ряд недостатков. Например, эти длинные селекторы утомительно писать руками. Среда разработки не понимает, что это имена компонент и ничего не подсказывает при наборе. Наконец, тайпскрипт тоже ничего про это соглашение не знает и не может протайпчекать селекторы.

Генерация стилей

Было бы классно описать наши стили прямо в тайпскрипте в простой лаконичной форме и автоматически сгенерировать из этого CSS.

[my_profile_details_body] {    overflow: 'overlay';}[my_profile_details_body] [mol_button] {    border-radius: .5rem;}

$mol_style_define( $my_profile , {    Details: {        Body: {            overflow: 'overlay',            $mol_button: {                border: {                    radius: rem(.5),                },            },        },    },} )

Тут мы вызываем функцию $mol_style_define, которая генерит StyleSheet. Передаём в неё класс компонента $my_profile и JSON, говорящий, что внутри компонента Details и его внутреннего компонента Body стили такие-то, а для всех вложенных в него кнопок сякие-то.

CSSOM: проблема с редактированием через DevTools

Генерировать стили можно двумя способами: либо через CSSOM, либо через генерацию портянки CSS и подклеивания его через элемент style. Если использовать первый подход, то в Chrome Dev Tools такие стили становятся не редактируемыми, что очень не удобно при разработке. Поэтому приходится использовать второй подход.

Сверху на скриншоте вы видите стили, сгенеренные библиотекой aphrodite, а снизу обычный CSS. Кстати, обратите внимание на порнографию в качестве селектора и сравните с теми именами, что генерит $mol_view.

Генерация CSS довольно простая операция. У меня это заняло 3КБ кода. Так что не будем особо на этом останавливаться и перейдём к типизации..

CSSStyleDeclaration: слабая типизация

В идеальном мире мы бы взяли стандартный тип CSSStyleDeclaration, поставляемый вместе с тайпскриптом. Это просто словарь из 500 свойств, типизированных как string.

type CSSStyleDeclaration = {    display: string    // 500 lines}

Соответственно, вы можете легко опечататься в каком-нибудь слове, а тайпскрипт это злополучно пережуёт и даже не подавится.

{    display: 'black' // }

csstype: кривая типизация

Можно взять популярную библиотеку csstype, которая генерируется из выгрузки всех свойств и их значений из MDN. Во второй её версии генерируются не очень полезные типы..

type DisplayProperty =| Globals| DisplayOutside| DisplayInside| DisplayInternal| DisplayLegacy| "contents" | "list-item" | "none"| string

Кто знаком с тайпскриптом, понимаю, что этот код эквивалентен следующему..

type DisplayProperty = string

Всё дело в том, что строковые литералы являются подтипами строки, потому тайпскрипт оставляет лишь наиболее общий тип.

csstype@3: кривая типизация с подсказками

Но ничего, в тетьей версии они это "починили" string соединили с пустым интерфейсом, из-за чего слияния с литералами уже не происходит:

type Display =| Globals| DisplayOutside| DisplayInside| DisplayInternal| DisplayLegacy| "contents" | "list-item" | "none"| (string & {})

Теперь типы не сливаются и подсказки всё же работают, но вы по прежнему можете опечататься и никто не ругнётся..

{    display: 'black' // }

Простые свойства

Мы пойдём своим путём и самостоятельно опишем типы для нужных нам свойств в том виде, который будет нам удобнее всего. Для этого заведём интерфейс Properties и будем заполнять его..

interface Properties {    /**     * Whether an element is treated as a block or inline element     * and the layout used for its children, such as flow layout, grid or flex.     */    display?: 'block' | 'inline' | 'none' | ... | Common    // etc}type Common = 'inherit' | 'initial' | 'unset'

Подсказки по свойствам

Для каждого свойства будем писать докстринг, который будет выводиться над именем свойства при наведении, что полезно тем, кто ещё не вызубрил все 500 CSS-свойств.

Группы свойств

Многие CSS свойства имеют общий префикс и было бы удобно не писать его каждый раз, а сгруппировать в один объект..

overflow: {    x: 'auto' ,    y: 'scroll',    anchor: 'none',}

interface Properties {    overflow? : {        x?:  Overflow | Common        y?:  Overflow | Common        anchor?: 'auto' | 'none' | Common    }}type Overflow = 'visible' | 'hidden' | ... | Common

Свойства размеров

Для размерностей есть не только предопределённый список значений, но произвольные юниты (1px, 2rem) и функции (calc(1rem + 1px)).

interface Properties {    width?: Size    height?: Size}type Size =| 'auto' | 'max-content' | 'min-content' | 'fit-content'| Length | Commontype Length = 0 | Unit< 'rem' | ... | '%' > | Func<'calc'>

Единицы измерения

Юнит можно объявить как просто класс, который параметризирован литералом и который умеет правильно себя сериализовывать.

class Unit< Lit extends string > {    constructor(        readonly val: number,        readonly lit: Lit,    ) { }    toString() {        return this.val + this.lit    }}

Так как литерал мы передаём в конструкторе, то типы экземпляров созданных с разными литералами будут различны, что не позволит, например, передать проценты туда, где ожидаются градусы.

function rem( val : number ) {    return new Unit( val , 'rem' )}{    width: rem(1) // Unit<'rem'>}

Функции

Аналогичным образом можно реализовать и функции. В них класс параметризируется не только именем функции, но и типом её содержимого.

Func<    Name extends string,    Value = unknown,> {    constructor(        readonly name: Name,        readonly val: Value,    ) { }    toString() {        return `${ this.name }(${ this.val })`    }}

function calc( val : string ) {    return new Func( 'calc' , val )}{    // Func< 'calc' , string >    width: calc( '1px + 1em' )}

Сокращённые свойства

Многие CSS свойства имеют как полную так и сокращённую формы. Например, для margin можно указать от 1 до 4 значений. И если для 1 и 2 всё более-менее понятно, то с болшим числом начинаются головоломки типа: если значения 4, то margin-left это последнее значение, а если 3, то предпоследнее. Чтобы такого не происходило, оставим лишь пару сокращённых форм, а если хочется большего контроля изволь написать в полной форме какому направлению какое значение. Получаем чуть больше писанины, но и улучшаем понятность кода.

interface Properties {    margin?: Directions<Length>    padding?: Directions<Length>}type Directions< Value > =| Value| [ Value , Value ]| {    top?: Value ,    right?: Value ,    bottom?: Value ,    left?: Value ,}

margin: rem(.5)padding: [ 0 , rem(.5) ]margin: {    top: 0,    right: rem(.5),    bottom: rem(.5),    left: rem(.5),}

Цвета

Для цветов у нас есть словарь $mol_colors из всех стандартных цветов просто берём из него ключи. Плюс добавляем несколько функций..

type Color =| keyof typeof $mol_colors| 'transparent' | 'currentcolor'| $mol_style_func< 'hsla' | 'rgba' | 'var' >color?: Color | Common

{    color: 'snow',    background: {        color: hsla( 0 , 0 , 50 , .1 ),    },}

hsl и rgb специально не добавлены, ибо написать лишнюю единичку для hsla и rgba не проблема, зато АПИ несколько упростили.

Списки

Порой свойство может содержать не одно значение, а целый список. Например, список фоновых картинок..

background?: {    image?: [ $mol_style_func<'url'> ][]}

background: {    image: [        [url('/foo.svg')],        [url('/bar.svg')],    ],},

Тут можно было бы запариться со специальными хелперными функциями, но писать их постоянно не очень практично, поэтому используется следующая простая эвристика: если в массиве лежат простые значения, то они просто соединяются через пробел. А если сложные (массивы, объекты), то через запятые. А вложенные в них значения уже через пробел.

Списки структур

Более сложный пример список из структур как в описании теней..

box?: {    shadow?: readonly {        inset: boolean        x: Length        y: Length        blur: Length        spread: Length        color: Color    }[]}

box: {    shadow: [        {            inset: true,            x: 0,            y: 0,            blur: rem(.5),            spread: 0,            color: 'black',        },    ],},

У тени много параметров, в которых легко запутаться, поэтому лучше писать имена параметров явно. При сериализации имена параметров отбрасываются, а значения соединяются через пробел. Особый случай булево свойство, если оно ложно, то игнорируется, а если истинно, то добавляется имя свойства.

БЭМ-элементы

Наконец, мы дошли до самой мякотки. У нас есть компонент $my_profile, в котором есть элемент Details, который сам является компонентом $my_panel, в котором есть элемент Body, который является компонентом $mol_scroll. И было бы неплохо уметь стилизовать любой из этих элементов, через стили, задаваемые компоненту $my_profile.

interface $my_profile {    Details(): $my_panel} )interface $my_panel {    Body(): $mol_scroll} )

$mol_style_define( $my_profile , {    padding: rem(1),    Details: {        margin: 'auto',        Body: {            overflow: 'scroll',        },    },} )

При этом хочется, чтобы тайпскрипт проверил, что указанные в стилях элементы действительно присутствуют в компонентах.

Поиск всех БЭМ-элементов

У нас есть специальная типофункция $mol_type_pick, которой вы передаёте некоторый интерфейс и желаемый тип полей, а возвращает она тот же интерфейс, но без полей, которые не соответвуют желаемому типу.

$mol_type_pick<    $my_profile,    ()=> $mol_view,>

interface $my_profile extends $mol_view {    title(): string    Menu(): $my_panel    Details(): $my_panel} )        {    Menu(): $my_panel    Details(): $my_panel}

В данном примере, у компонента есть свойство title, возвращающее строку. Но было бы странно вешать стили на строку. Стили можно вешать лишь на Menu и Details ибо они возвращают экземпляры компонент.

БЭМ-блоки

Вложенные компоненты порой хочется стилизовать не только по их локальному имени, но и по имени их класса. Например, мы хотим сделать вообще все кнопки по умолчанию красными, а кнопки на панели детализации синими.

interface $my_profile {    Menu(): $my_panel    Details(): $my_panel} )interface $mol_button {} )

$mol_style_define( $my_profile , {    $mol_button: {        color: 'red',    },    Details: {        $mol_button: {            color: 'blue',        },    },} )

Поиск всех подклассов

Найти все имена компонент не сложно, так как все классы, функции и прочие глобальные переменные объявляются в едином неймспейсе с именем $. Это позволяет воспользоваться тем же $mol_type_pick, чтобы выбрать все компоненты.

type $mol_view_all = $mol_type_pick<    typeof $,    $mol_view,>

namespace $ {    export class $mol_view {}    export class $my_panel {}    export class $mol_tree {}}        {    $mol_view: typeof $mol_view    $my_panel: typeof $my_panel}

Декларативные ограничения

Наконец, мы добрались до типизации функции-генератора в которую мы передаём компонент и описание стилей. Наивное описание типов для неё выглядит в декларативной форме по классу компонента генерируется развесистый рекурсивный тип со всеми возможными вариантами полей.

function $mol_style_define<    View extends typeof $mol_view,    Config extends Styles< View >>(    view : View,    config : Config)

type Config< View extends $mol_view > = {    $my_panel: {        $my_panel: {            ...        }        $my_deck: {            $my_panel: {                ...            }        }        ...    }    ...}

Проблема тут в том, что вкладывать друг в друга компоненты вы можете практически как угодно, и число различных комбинаций растёт экспоненциально от глубины. В результате тайпскрипт выжирает всю память и падает. А если и не падает, то начинает дико тормозить.

Не понятные типошибки

Но даже если вы дождётесь вывода типа, то сообщения ошибки вас не обрадуют, ибо из него не будет понятно где и почему возникла ошибка.

Императивные ограничения

Лучше в таком случае использовать императивный подход, где вы берёте фактический тип написанного пользователем JSON, в типогуарде проходитесь по нему и переданному компоненту и генерируете новый не рекурсивный тип, где оставлены лишь валидные поля и значения. А на не валидных тайпскрипт не сматчится и сообщит об ошибке.

function $mol_style_define<    View extends typeof $mol_view,    Config extends StylesGuard<        View,        Config,    >>(    view: View,    config: Config)

{    Details: {        foo: 'bar',    },}        {    Details: {        foo: never,    },}

Работает такой подход гораздо быстрее и кушает меньше памяти. Важно б этом помнить, когда пишете сложные типы, иначе придётся ждать подсказок по несколько секунд и порой получать фигу.

Всё ещё непонятные ошибки

Если просто возвращать never для не валидных значений, то сообщения об ошибке хоть и будут иметь координаты, но не будет понятна причина, почему написанный код не валиден.

Понятные ошибки

Вместо never лучше возвращать специальный тип, который ни с чем не сматчится и в котором литералом прописать суть сообщения об ошибке и дополнительную информацию.

В примерах мы сначала попытались навесить стили на несуществующий атрибут, потом на свойство, которое возвращает не компонент, а в конце просто написали какую-то балалайку, которую не удалось распознать ни как имя компонента, ни как имя элемента, ни как имя свойства.

Атрибуты

Кстати, об атрибутах. В $mol_view они задаются как метод возвращающий словарь из строки в примитив.

attr *    ^    mol_link_current <= current false        attr() {    return {        ... super.attr(),        mol_link_current: this.current(),    }}

Стили для атрибутов

Для описания стилей для атрибутов просто вкладываем друг в друга: собачка -> имя атрибута -> значение -> (стили, элементы и прочий фарш).

{    '@': {        mol_link_current: {            true: {                zIndex: 1            }        }    }}

Псевдоклассы и псевдоэлементы

Разумеется есть предопределённый список всех псевдоклассов и псевдоэлементов, которые можно использовать на любом уровне..

{    ':hover': {        zIndex: 1    }}

Медиа запросы

Так же можно вкладывать медиа-запросы. Это гораздо удобнее, чем в CSS, где медиа-запросы пишутся вне и требуют повторения селектора внутри.

{    $mol_scroll: {        overflow: 'scroll',        '@media': {            'print': {                overflow: 'visible',            },        },    },}

Непосредственно вложенные блоки

Наконец, с помощью угловой скобочки можно задавать стили лишь для непосредственно вложенных элементов.

{    '>': {        $mol_view: {            margin: rem(1),        },        $mol_button: {            margin: rem(0),        },    },}

Что получилось

• Каскадные переопределения стилей
• Тайпчек всех ключей и значений
• Подсказки по всем ключам и значениям
• Описание всех свойств
• Понятные сообщения об ошибках
• Удобство описания стилей

Что можно улучшить

• Рантайм чтение стилей до рендеринга (полезно для виртуализации)
• Типизация всех свойств (прогресс 10 из 500)
• Добавить все функции
• Поддержать анимации
• Типизированные выражения в calc (а не строка)

Попробовать вне $mol

Ести вас заинтересовал мой расказ и вы хотели бы попробовать поиграться с этим, но не готовы ещё перейти на $mol, то можете воспользоваться библиотекой mol_style_all, позволяющей описывать CSS-свойства.

import {    $mol_style_unit,    $mol_style_func,    $mol_style_properties,} from 'mol_style_all'const { em , rem } = $mol_style_unitconst { calc } = $mol_style_funcconst props : $mol_style_properties = {    margin: [ em(1) , rem(1) ],    height: calc('100% - 1rem'),}

codesandbox.io/s/molstyleall-ked9t

Там, конечно, нет генератора CSS, так как он сильно завязан на то, что генерирует $mol_view. Тем не менее, если вы заходите добавить эту функциональность к своему любимому фреймворку, то заходите к нам в чат mam_mol вместе подумаем, как бы это сделать.

Продолжение следует...

К сожалению, материала оказалось слишком много, поэтому пришлось разбить выступление на две части. Это была лайтовая чать про использование, а следующая уже будет хардкорная, где мы поговорим про программирование на типах и как реализовывать всё то, о чём я рассказал..

• Сравнение типов
• Типофункции
• Типотесты
• Типошибки
• Типогуарды
• Фильтрация интерфейсов
• Брендированные примитивы

Куда пойти

• eigenmethod/mol/style исходники
• mam_mol обсуждение
• nin_jin связь со мной
• habhub.hyoo.ru статьи
• _jinnin заметки

Обратная связь

• Хороший доклад. Хотелось бы побольше конкретных примеров. Вот у нас есть отрисованный дизайн, и вот, что мы написали, чтобы получился pixel-perfect.
• Очень быстро говорит! Не успеваешь понять и думаешь, что надо пересматривать и гуглить.
• Не работал с ТС, поэтому не могу обьективно оценить ценность трудов Дмитрия.
• Для меня не сильно профильно, непонятно и не очень интересно.

Здравствуйте, меня зовут Дмитрий Карловский и я тот ещё токсичный перец. Недавно я источал свои альфа-флюиды на Альфа-банк. Ребята в ответ поступили достойно, и не стали атаковать меня в личку объяснениями, как сильно я не прав, а завели задачу на гитхабе. И даже что-то пофиксили, сделав часть моих претензий несостоятельными. Но не ту часть, где SSR портит всё.

Время утекло, пыль улеглась, и тут история получает продолжение: недавно ко мне обратился продюсер контент-студии Хабра с предложением пропесочить их Торт. Что ж, расчехляем вентилятор!

Сложный случай

Возьмём, например, вот эту страницу, содержащую 2500 комментариев. Это настолько огромная страница, что если вы откроете её в Хроме, то он обрежет её уже на 1400 комментарии. Чтобы прочитать оставшиеся вам придётся открыть её, например, в Огнелисе. Причину этого оставим на совести разработчиков. Давайте лучше подумаем как этого не допустить. Но сперва проведём замеры:

Методика измерений

• Размер данных объём HTML или JSON выдачи. Показывается в девтулзах Хрома, если включить "широкие строки". Вес указан лишь того ресурса, что выдаёт комментарии.
• Размер сжатых данных то, что девтулзы показывают по умолчанию для загруженных ресурсов.
• Время полной загрузки время открытия всех комментариев (да, иногда Хром всё же рендерит всё не понятно от чего зависит), обычным секундомером на глазок от нажатия F5 (или ссылки "показать комментарии") до завершения всех видимых пользователю загрузок. Кеш отключался через девтулзы.
• Время показа первого экрана то же, что и время полной загрузки, но дожидаясь лишь появления контента, заполняющего весь экран, что позволяет начать его читать.
• Число DOM элементов выводился document.getElementsByTagName('*').length в режиме наблюдения, приведено максимально наблюдаемое число.
• Отзывчивость при прокрутке длительность блокировки основного потока при скроллинге на одну страницу. Замерялось через профайлер.
• Пересчёт лейаута длительность блокировки основного потока при однократном изменении размера окна. Замерялось через профайлер.
• Потребление памяти объём, который показывают девтулзы для основного потока, после полной загрузки и ручного запуска сборки мусора.

Для всех замеров использовался обычный домашний вайфай и ноутбук с развёрнутыми на пол экрана девтулзами. Если что-то не учёл обязательно докопайтесь к этому в комментариях.

Предварительный анализ

У Хабра есть две версии: десктопная и мобильная. Десктопная загружает статью со всеми комментариями единым HTML. Мобильная же поступает хитрее: сначала загружается статья в виде HTML, а по клику на кнопку "комментарии" она подгружает JSON с комментариями и рендерит их с помощью VueJS вместо статьи. Но если на комментарии зайти по прямой ссылке, то будет загружен пререндеренный HTML. Пререндеренный HTML ничем принципиально не отличается от десктопной версии, поэтому я замерял именно вариант с динамическим рендером, который отрабатывает в большинстве реальных сценариев использования.

Как видно, вес JSON примерно в 4 раза меньше HTML. В формате Tree эти данные весили бы ещё меньше, но парсились бы дольше, ибо кастомный парсер на яваскрипте даже более простого формата всё же медленнее нативного JSON парсера. В любом случае, после сжатия, которое применяется сейчас повсеместно, разница уже не столь существенна порядка 30%.

Пререндеренный HTML довольно долго грузится, это связано с двумя факторами:

1. Параллельно начинают грузиться все изображения со страницы, а это 8 мегабайт несжимаемого трафика, который капитально забивает канал. Решить эту проблему могли бы через loading="lazy", но не стали.
2. После загрузки очередного куска HTML происходит его подклейка в общее дерево, что вызывает повторное вычисление стилей, лейаута и рендеринга. Так как стоимость этого процесса растёт по мере роста DOM, то зависимость суммарной задержки загрузки от размера HTML тут экспоненциальная. Решается только одним способом уменьшением HTML.

При динамическом рендеринге загрузка данных происходит быстрее, но сэкономленное время компенсируется временем на работу яваскрипта по генерации DOM дерева. В обоих случаях пользователю приходится ждать не меньше полу минуты до возможности прочитать новые комментарии, что крайне долго. Также динамический рендеринг на VueJS не прогрессивен, то есть не позволяет начать чтение контента до его полной обработки.

Кроме того, использование VueJS даёт довольно серьёзное пенальти по памяти оно увеличивается более чем в 25 раз.

Всего на страницу выводится около 100K DOM элементов. Это в среднем около 40 элементов на каждый комментарий.

Браузеру становится очень плохо от такого большого DOM дерева и он начинает серьёзно тупить. Например, обновление экрана при скроллинге, не смотря на его аппаратное ускорение, занимает 700мс. И это чисто скроллинг, без пересчёта лейаута. С ним же почти 2 секунды. А пересчитывается лейаут почти на любое изменение DOM дерева. DevTools тоже порой сходят с ума, что осложняет профилирование.

Выбор стратегии

Основная причина тормозов размер DOM дерева. Поэтому требуется такая реализация, которая позволит иметь на пару порядков меньшее число элементов на странице. Выпишем возможные стратегии:

Выводы:

1. Виртуализация меньше всего расстроит пользователей.
2. Так как единовременно отображаются не все комментарии, придётся вручную реализовать поиск по всем комментариям.

Прототипирование

Самый простой способ воспользоваться виртуальным рендерингом переписать страницу на $mol, что позволит нам писать код даже не думая о виртуализации, но всё равно её получить, так как в $mol она встроена под капотом.

Хабр возвращает статью и комментарии в виде JSON. Давайте опишем его схему, чтобы тайпскрипт давал нам подсказки и тайпчек, а рантайм проверял, что выдача сервера соответствует ожидаемой. Для этого мы воспользуемся семейством функций $mol_data:

const Person = Rec({    id: Int,    login: Str,    avatar: Str,})const Comment =  Rec({    id: Int,    author: Maybe( Person ),    children: List( Int ),    message: Str,    timePublished: Maybe( Moment ),})const Comments_response = Rec({    comments: Dict( Comment ),    threads: List( Int ),})const Article = Rec({    titleHtml: Str,    textHtml: Str,})

Некоторые поля опциональны в них возвращается null для сообщений, оставленных НЛО.

Теперь мы можем легко загрузить данные, проверить их и вернуть типизированную структуру. Например, так выглядит загрузка комментариев:

@ $mol_memcomments_data() {    const uri = `https://m.habr.com/kek/v2/articles/${ this.article_id() }/comments/`    const data = Comments_response( this.$.$mol_fetch.json( uri ) )    return data}

Хорошо, данные мы загрузили, осталось их показать. Текст статей и комментариев Хабр возвращает в виде строки, содержащей довольно разношёрстный HTML. Для его отображения воспользуемся компонентом $mol_html_view:

<= Article $mol_html_view    html <= article_content \    highlight <= search    image_uri!node <= image_uri!node \

(Если вы не знакомы с синтаксисом view.tree, предназначенным для декларативной композиции компонент, то можете ознакомиться с кратким или полным его описанием.)

Этот компонент берёт HTML, парсит его и для каждого элемента создаёт соответствующий $mol_view компонент, а он уже сам себя виртуализирует. Кроме того, $mol_html_view позволяет указать строку, которая будет подсвечена в тексте.

Также нам потребовалось перегрузить метод image_uri, который вызывается для каждого IMG элемента, чтобы получить ссылку на картинку. Причина в том, что в атрибуте src в выдаче Хабра изначально находится лишь ссылка на заглушку, а реальная ссылка на изображение берётся из атрибута data-src. Поэтому реализуем этот метод так:

image_uri( node : HTMLImageElement ) {    return node.dataset.src || node.src || 'about:blank'}

Рендеринг дерева комментариев не представляет из себя ничего особенного. Разве что мы добавим возможность сворачивать/разворачивать ветки комментариев.

@ $mol_mem_keycomments_visible( id : number ) : readonly number[] {    if( this.comment_expanded( id ) ) {        return this.comments_all( id )    } else {        return this.comments_filtered( id )    }}

Эта функциональность полезна и сама по себе, но нам она ещё пригодится и для поиска. Дело в том, что $mol пока ещё не умеет прокручивать сролл к заданному компоненту. Штука эта вполне реализуема, но у меня руки пока не дошли, так что если если кто-то возьмётся за это дело было бы супер.

А сейчас, мы, вместо прокрутки страницы между найденными постами, будем сворачивать все ветки комментариев, где искомая подстрока в тексте не встречается. Таким образом пользователь может ввести запрос и просто скроллить страницу. А при желании развернуть ветку и почитать все ответы. Выглядит это примерно так:

Многие пользователи привыкли к хоткею Ctrl+F для поиска по странице, поэтому добавим плагин $mol_hotkey для его перехвата:

plugins /    <= Search_key $mol_hotkey        mod_ctrl true        key * F?event <=> search_focus?event null    <= Theme $mol_theme_auto

Ну а для фокусирования просто доберёмся до нужного нам компонента и скажем ему сфокусироваться:

search_focus( event : Event ) {    this.Search().Suggest().Filter().focused( true )    event.preventDefault()}

Обратите внимание, что мы так же добавили плагин $mol_theme_auto, который автоматически ставит светлую или тёмную тему в зависимости от предпочтений пользователя.

Кроме того, добавим пользователю возможность вручную менять тему, разместив на тулбаре кнопку $mol_lights_toggle:

tools /    <= Lights $mol_lights_toggle    <= Sources $mol_link_source        uri \https://github.com/nin-jin/habrcomment    <= Search $mol_search        query?val <=> search?val \

Заодно мы тут расположили стандартную ссылку на исходники и поисковое поле, связав его двусторонней связью с поисковым запросом.

Наведём немного красоты, переопределив некоторые дефолтные стили, используя модуль $mol_style, который обеспечивает тайпчек и подсказки, учитывающие реальную иерархию компонент:

$mol_style_define( $my_habrcomment , {    Orig: {        flex: {            grow: 1,            shrink: 0,            basis: per(50),        },    },    Article: {        maxWidth: rem(60),    },    Comments: {        flex: {            shrink: 0,            grow: 1,        },    },    Comments_empty: {        padding: rem(1.5),    },} )

Последним штрихом добавим поддержку оффлайна:

include \/mol/offline/install

Этим не хитрым кодом мы установили кеширующий Service Worker, который в случае проблем с соединением будет выдавать данные из кеша.

Не то чтобы оффлайн и переключение цветовых тем были необходимы, но если есть возможность практически бесплатно получить вау фичи, которых нет в оригинале, то почему бы и нет.

Что ж, вот наш прототип читалки хабракомментариев и готов: https://nin-jin.github.io/habrcomment/#article=423889

Держите букмарклет, позволяющий открывать в ней любую тяжёлую статью:

document.location = document.location.href.replace( /\D+/ , 'https://nin-jin.github.io/habrcomment/#article=' )

Анализ прототипа

Код исходников уложился в 400 строк, на написание которых требуется не более пары часов. По функциональности:

• Отображение произвольной статьи с форматированием
• Отображение дерева комментариев к статье с форматированием
• Возможность сворачивать/разворачивать комментарии
• Поиск по статье/комментариям с подсветкой найденного и сворачиванием лишнего
• Работа в оффлайне
• Поддержка тёмной/светлой тем
• Адаптивность к размеру экрана

Мы добились ускорения полной загрузки огромной страницы в 5 раз. А потребление памяти уменьшилось в 6 раз по сравнению с мобильной версий (и в 2 раза, если отключить виртуализацию). Для мобилок это куда актуальней, чем для десктопа. При этом мы ещё даже не приступили к собственно оптимизации кода.

Если пошаманить можно выиграть ещё несколько секунд. Например, в наивной реализации HTML всех комментариев парсится при открытии страницы для расчёта их минимальных размеров исходя из содержимого. Однако, можно руками задать какое-то константное значение, меньше которого текст комментария точно быть не может:

<= Message $mol_html_view    minimal_height 60    highlight <= search \    html <= message \    image_uri!node <= image_uri!node \

Таким образом парсинг HTML будет происходить лишь при фактическом отображении. Позиция скроллбара, конечно, тогда будет рассчитываться несколько менее точно, но это не страшно.

Итого по скорости загрузки: почти десятикратное ускорение полной загрузки при сохранении времени появления контента в 5 секунд.

А если есть возможность менять API, то можно пойти ещё дальше изначально загружать лишь информацию о вложенности комментариев, а собственно информацию по ним загружать лениво, по мере необходимости. Благодаря виртуализации необходимость эта будет возникать лишь при приближении комментария к видимой области. А самое примечательное, что для перехода на ленивую загрузку даже не придётся обновлять вьюшки достаточно обновить код получения данных. Аналогичным образом легко и переключить клиентский поиск на серверный:

@ $mol_memcomments_data() {    const search = encodeURIComponent( this.search() )    const uri = `https://m.habr.com/kek/v2/articles/${ this.article_id() }/comments/?search=${search}`    const data = Comments_response( this.$.$mol_fetch.json( uri ) )    return data}

Реализована сейчас, разумеется, не вся функциональность. Но всё остальное особой погоды не делает. Чтобы довести до продакшена, надо будет ещё много чего реализовать. Если кто-то готов этим заняться можете попробовать. Правда сперва придётся договориться с руководством Хабра об использовании их API. Я пробовал несколько раз подкатить с разных сторон никакого ответа не получил.

Также можно заметить, что отступы вокруг разных комментариев пляшут как попало это от того, что HTML, отдаваемый Хабром, это какая-то дичь от слова совсем: слова то в параграфах, то в дивах, то параграфов вообще нет, а абзацы разделяются переводами строк или тегом BR, что вообще вырубает виртуализацию. В общем, тут надо либо чтобы Хабр отдавал что-то единообразное и валидное, либо пилить какой-то свой нормализатор выдачи.

$mol_html_view поддерживает сейчас лишь сравнительно небольшой набор HTML-элементов далеко не всё, что может выдавать Хабр. Добавить поддержку остальных в принципе не сложно и она, конечно, будет расширяться по мере необходимости.

Кроме того, есть и технические косяки:

1. Контент при скроллинге иногда скачет это какой-то косяк в логике виртуализации $mol_list. Не приятно, но жить можно. Как-нибудь конечно же починю.
2. В сафари автоматически отключается виртуализация сверху, так как он не поддерживает overflow-anchor, необходимый для того, чтобы можно было менять контент сверху от видимой области без скачков видимого контента. Это означает, что страница будет открываться всё так же быстро, но по мере прокрутки вниз будет дорендеривать всё остальное содержимое, пока не отрендерит все 100K элементов, когда пользователь домотает до самого конца.

А вот появление горизонтального скролла на узких экранах и глубоких обсуждениях это не баг, а фича. Лучше уж иногда скроллить в сторону, чем вообще терять понимание какой комментарий на какой отвечает начиная с определённого уровня, как это происходит в оригинале. А вот на широком экране мы не ужимаем все комментарии в одну узкую колонку, а занимаем столько места, чтобы их было комфортно читать.

Резюме

1. SSR не быстрее грамотной реализации PWA.
2. Вместо поддержки двух абы как слепленных реализаций для разных девайсов, лучше потратить это время на одну, но толковую и адаптивную.
3. Выбирая между двух зол, лучше сделать шаг в сторону возможно именно там расположилось добро.
4. VueJS тупит, а $mol рулит.
5. Браузеру становится очень плохо, когда в доме много элементалей.
6. Стоит предпочитать те решения, что не приводят к не контролируемому увеличению числа элементалей в доме.

Ссылки

1. Исходники читалки можете заметить, что кода там всего ничего.
2. Страница фрейморка $mol ужаснитесь сколько всего у нас там есть.
3. Канал с новостями о $mol и MAM подписывайтесь, чтобы быть в курсе всего важного, что с ними происходит.
4. Канал с видео о $mol когда-нибудь тут появятся видео-туториалы.