Решил предложить в качестве идеи на подумать такой вариант - https://yadi.sk/i/HLM1KIHIYexBG Заголовок - над подписью, подпись меньше и убрать решетку с номером непонятно чего ;)

Ожидаемое поведение - открытие формы добавки поста с чекнутым bem-forum

Пока наш форум далек от идеала, но мы работаем над этим. И в этом процессе без вас не обойтись!

Поэтому, если вы заметили, что что-то не работает или работает не так, и как вам бы того хотелось, пишите про это пост прямо в форум с меткой bem-forum.

Предлагается написать блок для реализации сетки. Блок должен учитывать сетку из проектов Яндекса в новом дизайне, использующих bem-components. Я предлагаю взять для начала сетку реализованную мной тут. Это фактически порезанный порт сетки из Foundation. А затем следующей версией внедрить поддержку flexbox, чтобы можно было поддерживать старые браузеры. @tadatuta предлагал писать сразу, используя flexbox, а старые ie поддерживать отедльным css. Все заинтересованные лица приглашаются к обсуждению.

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

Обязанности bem-deps

• инкрементальное накопление зависимостей в объектной модели
  • приём зависимостей в унифицированном формате
• сериализация и десериализация накопленных зависимостей в унифицированный формат и из него (сохранение и чтение)
• манипуляции с множествами зависимостей
  • объединение
  • пересечение
  • вычитание
• вычисление упорядоченного множества БЭМ-сущностей из объектной модели дерева зависимостей по заданным критериям
• инструменты для парсинга зависимостей из исходников

  Архитектура bem-deps

  Класс DepsContainer

Контейнер для инкрементального накопления зависимостей.

Методы инстанса:

• add(deps) — добавляет информацию о зависимостях в контейнер; deps — чанк, описывающий зависимости в унифицированном формате
• serialize() — сериализует информацию в унифицированный формат
• forEach() — хелпер, позволяющий получить необходимое подмножество из объектной модели зависимостей

Статические методы:

• deserialize() — фабрика, создаёт инстанс DepsContainer из сериализованного формата

  Формат для хранения зависимостей

TBD

Формат для накопления зависимостей

{
  deps: [
    {
      block: 'block-name', // имя блока
      elem: 'elem-name', // имя элемента
      mod: 'val' || true // имя и значение модификатора, `true` в качестве значения для булева модификатора
      priority: true // флаг приоритета зависимости
    }
  ],
  priority: [] // массив для указания приоритета зависимостей без их включения
}

Хелперы для парсинга зависимостей из исходников

Базовый класс DepsParser()

Абстрактный класс, задаёт интерфейс для парсеров зависимостей.

Класс DepsJsParser()

Парсер исходных файлов deps.js.

Класс DepsYmlParser()

Парсер исходных файлов deps.yaml.

Класс YmParser()

Парсер исходных js файлов, использующих модульную систему ym. Полезен при условии, что имена модулей однозначно соответствуют описываемых в них БЭМ-сущностям.

Утилиты

Утилиты возвращают новый инстанс DepsContainer с вычисленными зависимостями:

• subtract(source, subtraction...)
• merge(source...)
• intersect(source...)

Analyze — пакет, который строит объектную структуру проекта. Первая цель — генерация UML-диаграмма классов и взаимодействий, которая бы не протухала.

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

Работает на провайдерах.

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

Но провайдер jsdoc работает на BT-шаблонах.

Есть провайдер для модульной системы, написанной dfilatov.

Есть дополнения.

CLI Единственная команда report — загружает конфиг .analyze.js (если есть), вынимает оттуда директории проекта, анализиует проект (все файлы с расширением js, но не test.js). Каждый файл обрабатывается отдельно.

Каждый провайдер возвращает данные, на основе которых формируется общий результат.

Пост-обработка — построение зависимостей (между классами).

Набор зависимостей — это отдельная сущность.

Обработка:

1. Фильтры (из общей структуры остается какой-то необходимый сабсет) source target show — общая картина, все связи (source + target)
2. Валидация (не связан со структурой, указывает на какие-то несоответствия, например, обязательное наличие return type) ErrorLog — в него пишут провайдеры и валидаторы Валидаторы имеют настройки в CLI.

На данном эта получаем Объектная модель (инстанс Project) и инстанс ErrorLog (включает указание на строку с ошибкой)

1. Репортер

Настройка node.js-модуль экспортирует функцию, которая настраивается конфигуратором.

Планы на будущее Команда репорт не будет иметь предустановленных стратегий анализа (стратегии будут описываться отдельно). Будет возможность в js-файле описывать стратегии.

Хочется: builder (сделать настраиваемый, который бы можно было переопределять) стратегии (какой проект) вызывает процессоры про каждую сущность

file-analyzer -> js-file-analyzer

История разработки

BT-json -> MD + вставки ```BT-json, примеры и документация по js из jsdoc.

BEViS-doc-builder включает две технологии для генерации одно- и многостраничной (для Dash) документации.

---

Есть предложение, что нужно делать tool-chain из модулей с API, решающих конкретные задачи. И в этом контексте есть идея, что можно вынести из ENB ядро (task + node + target), для решения задачи сборки без привязки к предметной области.

У Марата нет уверенности, что устройство на node&target — это хорошо, т.к. понятие ноды излишне конкретное. Для сборщика общего назначения есть смысл оставить только target-ы (таски).

---

node - это папка (частный случай task) target - файлы либо папки, которые лежат в node task - как в Гранте, но без параметров (именованная задача, которая может использовать другие task).

Здесь собираем варианты API TechBuilder, выбираем наиболее подходящий.

Пока @veged не закрыл песочницу, скажите, как лучше подключать плагины?

---

Вариант нумер 1 с ручным переопределением, доопределением некоего объекта BEM. Плагин выглядит так:

module.exports = function (BEM) {
  // пишем команду
  BEM.command.cmd()
    .opt()....end()
    .act(function () { ... });
  // работаем с внуренностями
  BEM.levelManager.get('somelevel').doSomething();
  BEM.techManager.get('uberstrings').makeMeHappy();
  // добавляем какой-то метод и объект
  BEM.mySpecialMethod = function ... ;
  BEM.superContainer = { ... };
};

---

Вариант нумер 2 с предоставлением интерфейса с ym. В этом случае можно даже зафризить объект, чтобы не было желания работать через "глобальный" объект BEM. Т.е. некий jail.

module.exports = function (BEM) {
  // отдаем объект coa, который подкоманда abc
  BEM.defineCmd('abc')
    // тут лучше оставить как есть, решение хорошее
    .opt()...end().act(...);
  // внутренности закрываем
  BEM.requireLevel(['somelevel'], function (somelevel) {
    somelevel.doSomething();
  });
  BEM.requireTech(['uberstrings'], function (uberstrings) {
    uberstrings.makeMeHappy();
  });
  // добавляем какой-то метод
  BEM.define('bem', function (provide, bem) {
    bem.mySpecialMethod = ...;
    bem.superContainer = { ... };
    provide(bem);
  });
};

---

Вариант нумер 3. Как 2, но через "промисы":

module.exports = function (BEM) {
  BEM.defineCmd...
  // fail навешиваем в BEM.requireLevel, если он не найдется.
  BEM.requireLevel('somelevel').thenCall('doSomething');
  BEM.requireTech('uberstrings').then(function (uberstrings) {
    uberstrings.makeMeBoring();
  });
  BEM // или просто define
    .defineProperty('mySpecialMethod', function ...)
    .defineProperty('...');
});

---

"Зачем нам этот огород?" — спросите вы. Все просто. Менеджер уровней и уровни, которые есть в bt1.0, предлагается спрятать в пакете bem-levels, допилить, и подключать как-то так:

module.exports = function (BEM) {
  require(level), require(levels), ...
  var levelManager = new ...
  BEM.define('levels', function () {
  });
  BEM.on('ready', function () {
    levelManager.cd( BEM.require('config').cwd() );
  });
}

Аналогичным образом, еще до bem-levels, подключится bem-config, и скажет, что он определяет config. За ними bem-deps, bem-make, build, decl, etc. Все эти команды должны иметь 1 понятный интерфейс, чтобы работать с бэм-предметной областью, а не js-объектами, методами, магией.

---

p.s. Мне кажется, тут всем нравится api у coa. Можно выкинуть пачку методов для каждого define*, примерно как в 3. Фактически, через плагины нужно будет работать с уровнями, технологиями, командами. Последние две можно описать тасками (или, как минимум, наследоваться от него). Таким образом, получится команда — coa, технология и уровень — какое-то api. Похожим образом сделано в enb: defineНечто(...).настройка1(...).настройка2(...).etc().

---

p.p.s. Призываю к голосованию потенциальных авторов команд, технологий, и других плюшек. Каждый голос важен!

Конспект встречи Арикона с Лешей Ярошевичем

bem-tools 2.0 — это модульная штука, где ядро — это небольшая программа, использующая COA и для которой можно писать библиотеки.

Все, что относится к командам и АПИ реализуется в виде АПИ.

Уже сейчас с командами сделано, так, что команды можно расширять. Это сделано за счет COA.

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

Но как писать эти команды? Копипастить код из текущих bem-tools плохо, т.к. будет много копипаста. Так что нужно вынести куда-то общебэмовую функциональность:

• bem-config, который умеет читать common-js модуль. Когда программе нужна какая-то настройка, она дергает функцию из конфига (у нее зовется коллбек).
• Уровни (bem-levels)
  • чтение конфигов
  • интроспеция
  • создание уровня
• deps (bem-deps)
  • stub
  • parse
  • Deps
  • merge
  • intersect
  • substruct

Служебное низкоуровневое API (bem-util):

• map
• reduce
• translate
• create (new)

Build берет на вход декларацию (список) и технологию, а на выходе получается как правильно одна сущность — reduce (получает размеченный список сущности, у которых уже есть технология).

translate — это часть bem create, которая из одного файла технологии получает файл в новой технологии.

В bem-tools 2.0 хочется писать технологии не для команд bem create/ bem build, а технологии для сборки. Они будут работать по-разному в зависимости от необходимой собираемой технологии и вызывать внутри себя bem reduce, bem translate, etc.

bem-sets — это форк bem-pr, который отличается по интрефейсу, т.к. служебные библиотеки нужно подключать как npm-модули. Теперь bem-sets расширяются для сборки документации.

bem map — на входе несколько уровней и декларацию, а на выходе не одна сущность, а пачка значений. Пришедший набор в декларации возвращается таким же набором, но как-то трансформированным. Нарпимер, был были common.blocks + desktop.blocks и в результате examples собираются смерженными по специальным правилам.

taffyDB (?)

Пакет bem-tools по зависимостям тянет стандартные модули.

bem make будет отдельным пакетом.

https://github.com/bem/bem-tools/pull/502

// cc @zxqfox

https://github.com/bem/bem-tools/pull/271

// cc @arikon @zxqfox