Историческая справка
До недавнего времени мы работали над возможностью генерации Virtual DOM на основе BEMHTML-шаблонов. Мы разработали специальный движок для bem-xjst – xjst-ddsl, который может превращать шаблоны в некий DDSL, который с помощью дополнительного хелпера – ddsl-react превращался в React. Это было сделано для того, чтобы отделить специфику React и сделать закладку на тот случай, если захочется другую реализацию Virtual DOM. Об этом рассказывал я, например, на Я.Субботнике. Мы выдвинули и даже математически доказали гипотезу об эффективности этого метода, поскольку он позволял в 10 раз ускориться на сервере относительно нативного рендеринга на React, ведь на сервере мы можем использовать стандартный рендер в HTML, так как шаблоны одни.
Спустя некоторое время
Все это время мы делали подход в опенсоре – react-bl и внутри на реализацию компонентов для React на BEMHTML-шаблонах. Внутри мы попробовали очень большой объем компонентов, в том числе и составные/сложные с попапами и модальными окнами.
В чем разница открытой версии и внутренней?
В react-bl мы пробовали писать React-код для клиента "сверху" верстки и шаблонов, чтобы не трогать сами шаблоны и пробрасывать биндинги через пропсы компонентов. То есть получался "настоящий" React-компонент, где только разметка генерировалась с помощью BEMHTML. Такой подход нёс в себе несколько проблем. Во-первых, не работали уровни переопределения для клиентского кода, только для верстки в шаблонах. Во-вторых, добавлял иногда большие трудности при пробрасывании пропсов во вложенные элементы, тем более, если они строились динамически и имели вариативность.
Основываясь на этом опыте внутри мы попробовали писать клиентский код прямо в BEMHTML шаблонах. Например так:
block('link')(
tag()('a'),
js()(function() {
return {
onClick: () => console.log('hi there')
};
})
);
Это позволило решить проблемы с уровнями переопределения. И декларацией клиентского кода для вложенных элементов. Но... Нам пришлось добавить немного магии в ddsl-react (тот самый хелпер, что превращает DDSL в React). Мы добавили автоматический биндинг контекста. Ведь клиентский код в шаблонах ничего не знал про инстанс React-компонента и мы сделали это автоматически.
Кроме того, скорее всего вы спросите...
Как же было дело со вложенными компонентами?
Вопрос о том, что если кнопка использует иконку, а иконка тоже компонент? Ведь вызов иконки описан в BEMHTML и это просто BEMJSON, а не какой ни React-component. Мы решили эту проблему полуавтоматически: во время обьявления класса мы используем хелпер (ddsl-react), который первым аргументом принимает обьект с матчингом блоков на React-компоненты. Внутри во время рендера, когда встречается блок из матчинга он подменяется на React-компонент. Ведь разработчик знает, что за блоки используется в составном среди BEMHTML.
Что стало?
К сожалению, мы не учли несколько нюансов, и как мы ни пытались их обойти, сделать это эффективно у нас не получилось. А именно:
- проблема автоматического биндинга контекста: это очень большая магия и возникают неоднозначности при обращении к элементам из блока или к другим элементам из элемента
- проблема проставления refs, в 99% случаев все хорошо, но только не когда нужен ref на вложенный элемент в блоке, который вложен в другой блок
- слишком строгие правила для написания шаблонов чтобы серверный рендер работал действительно быстро. То есть клиентский код должен быть вынесен в другой уровень относительно верстки и это надо учитывать в сборке. В противном случае среди рендера BEMHTML функции React по прежнему выполнялись, что сильно замедляло процесс
Всё прям плохо?
На самом деле нет. В 99% случаев решение работает и работает хорошо. Просто ожидаемый профит показался недостаточным. Нам хотелось быстрый рендер на сервере и удобное написание React-компонентов. Опытным и трезвым умом нам показалось что мы этого не достигли. Тем не менее использовать BEMHTML-шаблоны в React можно, но базировать на этом библиотеку с компонентами не стоит. Если у вас есть желание работать с этим решением, я с радостью помогу разобраться и раздам прав. Мейнетейнеры нынче в цене.
Что дальше?
Мы проверяем новую гипотезу в bem-react-core. Это очень маленькая по обьему библиотека, которая позволяет декларировать React-компоненты в BEMHTML подобном синтаксисе, писать на последнем стандарте, собираться чем угодно(webpack, gulp, rollap, babel), поддерживает уровни переопределения и все все, что мы так любим. В репозитории есть набор примеров, которые можно посмотреть и понять. Мы работаем над новым набором компонентов в bem-react-components. Внутри мы так же попробовали очень много компонентов и кажется все очень хорошо. У нас уже почти готова документация и скоро она появится в репозитории. И так же скоро появится поддержка i18n ;) Приходите с PR и хейтерством. Все что мы запланировали пока, кажется отражено в issues.
Код для привлечения внимания
