Я не встречал обсуждения по этому вопросу, поэтому открою новую тему.
Кажется, что для достижения цели собирать в бандл только нужные сущности, было бы неплохо разнести декларации зависимостей по конкретным технологиям. Уже сейчас это возможно для клиентского JS при использовании технологии enb-modules/deps-with-modules, но совсем круто было бы иметь возможность делать так и в серверном JS (сейчас это обычно "привы"), и в BEMHTML/BH, и в CSS.
Есть технология deps-by-tech, но лучше было бы декларировать зависимости там, где это нужно непосредственно - в коде технологий и еще лучше там, где это возможно, получать зависимости явно через DI. Мне кажется, YModules в клиентском JS - очень удачный пример.
@Andre-487 Эта идея время от времени всплывает. С ней минимум две проблемы: 1) Далеко не всегда можно вычислить зависимости. Например:
2) Такой умный парсинг зависимостей очевидно негативно скажется на скорости сборки.
Но, скажем, из CSS вынимать зависимости можно однозначно и достаточно дешево по времени. Из декларации YM, как ты и написал, можно однозначно вынимать знания про необходимые блоки, но, например, нельзя про модификаторы.
Для некоторых кейсов можно пытаться «угадывать», закладываясь на наличие полей про БЭМ. Но, конечно, для продакшена такой наивный подход работать не будет.
Так или иначе, мы планируем еще раз поисследовать эту тему, когда появится реализация для bem-deps.
Речь как раз о том, чтобы реализовать технологию без магии и вытягивания зависимостей из существующего кода. Нужно попробовать придумать способы объявить зависимости, как это делается при DI.
Для CSS, например, можно использовать кастомное правило:
Для YM можно попробовать решить задачу разными способами, например, сделать возможность на уровне самих YM объявлять кастомные декларации, определяемые плагинами, и написать плагин, который разбирает зависимости предметной области BEM:
Или для i-bem использовать независимый DI:
Для BH можно использовать что-то такое:
Ну и так далее.
Вообще, видно, что все выглядит совершенно неконсистентно, но это вызвано тем, что технологии сами по себе имеют очень отличающийся синтаксис или набор инструментов.
@Andre-487 Что ты имеешь в виду, когда пишешь DI?
Если Dependency Injection, то я всё равно не понял, что ты имеешь в виду. Поясни, пожалуйста.
Именно. Имеется в виду, что ты в коде объявляешь, какие зависимости хочешь получить и получаешь их явно в том же коде. Некоторая разновидность этого паттерна реализована в YModules
да, мы давно думаем об этом — проблема в том, что не у всех технологий есть синтаксис для описания зависимостей, поэтому в новых депсах (https://github.com/bem-incubator/bem-deps https://yadi.sk/i/mqzMJpulhmXXm) подразумевается возможность написать кастомный вычислитель зависимостей из файла и общие deps.js «как сейчас», т.е. там где возможно можно будет писать зависимости, как ты выражаешься, через DI, а в остальных случаях в отдельном файле
отдельно замечу, что цель «собирать в бандл только нужные сущности» решается с помощью depsByTech
Мое предложение именно в том, чтобы по возможности использовать DI, а не использовать как красивое название ) Помимо сборки это даст большой профит при тестировании и сделает блоки более независимыми. Кажется, что это возможно везде, где чистый JS. В CSS или BEMHTML вряд ли можно говорить о DI, там действительно можно разве что указать зависимости прямо в коде.
Это круто. А есть где-то Roadmap по этому проекту? Когда можно будет воспользоваться или чем помочь?
Да, эту технологию можно использовать, пока нельзя хранить зависимости рядом с кодом. Но хотелось бы как-то более красиво вывести эту тему.
я не очень понимаю, что именно от DI тебе хочется использовать — по моему наши уровни переопределения дают всё нужное с точки зрения функциональности, а как именно записываются зависимости в коде или в файле рядом, это не принципиально с этой точки зрения
https://github.com/bem-incubator/bem-deps — всё в issues
Уровни переопределения - в принципе, дают. Но хочется получать зависимости не в глобальную ОВ, а в область конкретного блока. Примерно это делают YModules.
А в issues там негусто =) Есть 3 issues, где все как-то очень абстрактно.
@Andre-487 пишем спеки, параллельно с этим пишем код, который покрывается спеками (типа, BDD), вроде, все понятно ;-)
/cc @blond
WEB NOT SHIT!
@aristov Я слышал такие идеи - чтобы компонент был не просто набором технологий в виде файлов в одной папке, а писался прямо в одном файле. Даже высказывалась идея использовать markdown, для которого уже реализованы плагины для подсветки кода.
Если получится когда-нибудь сделать наши технологии настолько гибкими, чтобы они позволяли описывать способы хранения кода и зависимостей с помощью плагинов, получилось бы интересное решение. Но в качестве единственного лично я бы его не хотел )
Какие ещё решения могут понадобиться?
Ну, классическая организация на ФС: папка - компонент, файлы - технологии. Внутри каждой технологии объявляются зависимости.
Зависимости при этом могут объявляться по-разному: разные виды DI (репозиторий, внедрение в стиле YModules/Electrolyte), модули CommonJS, странные комментарии (мало ли, кому-то нравится олдскул).
Делаем консистентно:
select.bem.html
select.js.html
select.bemhtml.html
select.css.html
select.spec.html
select.bh.html
select.nodejs.html
Кому нравится - тот пишет себе чудо-парсер, приводящий зависимости к каноническому виду.
Как основной вариант, это все-таки не подойдет: слишком чуднО и инструменты не смогут распарсить зависимости.
Но модульность позволила бы и такой вариант использовать. Модульность - это вообще серьезный драйвер распространения технологии за счет гибкости.
Почему?
Потому, что это не похоже ни на что существующее и инструменты не будут понимать, что разные секции этого файла соберутся в разные сущности.
Хотя, опять же, я только за возможность реализовать такой синтаксис как один из вариантов, определяемых плагинами.
Сущность-то как раз одна. Технологии разные.
Весь код который поле этого написан))) в принципе не плохая идея для плагина под https://github.com/posthtml/posthtml :D