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

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

Еще будет проблема с зависимостями по State — если хочешь добавить какую-то новую смысловую единицу — опиши как она будет работать со всем имеющимся. Это не так-то просто.

И еще лучше не завязываться на разделители ;-).

Попытка крутая, спасибо что зашарил.

p.s. Еще я не очень понял, почему ты не пытался смотреть в сторону всяких имеющихся трасляторов, типа http://stackoverflow.com/questions/1618038/xslt-equivalent-for-json и http://speranskydanil.github.io/json-translator/ — потому что они не знают про BEMS? наверное, да.

Спасибо за рецензию!

Да, фолбэк предполагается. Это будет не json, а такой вырожденный js

Хочу, чтобы most used cases покрывались декларацией, а там где декларация могла бы стать очень намагиченной не придумывать её, а использовать js

Клёво запилить такой JS(ON) конвертор JSON -> (BEM)JSON, совсем как XSLT, да но в привязке к БЭМ(С)

Имеющиеся JSONT* as is не подойдут т.к. слишком общие, но могут стать ядром имплементации.

p.s. XSLT, IMHO, страдает тем, что не адаптируется под декларативную XML и юзает вполне себе императивный синтаксис и получается это криво.

Про XSLT — есть такое. Как и во множестве других попыток перенести XSLT в js (коей является XJST, кстати говоря).

Но на другие конверторы все равно посмотри, так или иначе все завязываются на XSLT и пытаются перенести это в JS. Чужой опыт будет полезен как никогда.

Буду смотреть :)

Про state буду думать, я пока те кейсы обдумал, которые пришли в голову.

Например, на state нельзя матчиться в XJT, но можно в i-bem Для обычного i-bem state может выглядеть неотличимо от mod

Есть потенциальная хрупкость разделения mod/state, попробую начать "конвертировать" проект Я.Картинок, тогда всё и "устаканится"

Да, большой проект сильно поможет понять проблемы в концепции и шлефануть реализацию. ;-)

из json трансформаторов я очень люблю пользоваться jq, он оказал влияние на запись доступа к данным . .key .key.nestedKey

Я так и не понял чем не подошёл BEMTREE? Можешь развернуто ответить?

UPD: 15:00 8 марта

Привет, дам развёрнутый, но наверно сумбурный ответ.

tl;dr: Диссонанс: утверждается, что BEMTREE = декларативность, но на деле нужно писать много кода на js ==> зашумленность, сложность

См. сравнение bemtree и xjt. Допускаю, что этот вымышленный bemtree-файл не является типовым, буду рад посмотреть на такие примеры.

У нас в Картинках bemtree не используется, но из того что я видел, ситуация там схожая с bemhtml. Немного смещённой статистики по bemhtml Сейчас проверил, у нас например 286 bemhtml.js файлов, 224 (ок. 70%) из них используют функции. Под сотню содержат логические операторы && || Такая же примерно картина и в СЕРПе. Поискал по яндекс коду, нашёл некоторые сервисы, использующие bemtree, например wiki. У них немного xjst-файлов и в половине есть нехорошие признаки. И это не от того, что у нас код кривой (хотя и не без этого).

Немного примеров: Чтобы добавить модификатор нужно написать что-то типа def()(function(){this.mods = this.extend(this.mods || {}, {/*mods*/}); return applyNext()}) возможно это из-за того, что считается, что модификаторы не нужно проставлять в шаблоне, но тут, ИМХО, проблема в том, что модификаторы модификаторам рознь.

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

Если привы писать свободно от представления, то в BEMTREE появляются map'ы со сложными функциями внутри.

Операции пере- и до- определения очень часты, и их приходится выполнять очень императивно. Вместо этого предлагаются Merge strategies (подробности)

На каждом шагу API шаблонизатора подталкивает забыть про декларативность и написать js код

PHP ugly style: BEMJSON используется на двух этапах шаблонизации и позволяет детально описывать представление, как следствие, многие привы у нас описывают и маппинг данных и логику, и представление (почти как в PHP) (XJT принимает не BEMJSON, а просто JSON что исключает скатывание в PHP)

Далее, BEMTREE, это просто урезанный BEMHTML, но на этом этапе хочется чего-то существенно отличающегося. Чего-то что позволяет решать задачи по переводу JSON в BEMJSON более лаконично.

Границы между priv, bemtree, bemhtml размыты (обозначены на уровне соглашений, которые не исполняются). Вот пример ужасающего bemhtml