Обсуждение bem-deps

Форум /

Обязанности `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...)

11 years ago

SevInf

Раз уж речь о депсах, я бы предложил разделить необходимость подключения зависимости и порядок включения. Как уже замечали, should, must и include: false - непонятная и нелогичная штука. Например:

{
    deps: [
        {block: 'a'},
        {block: 'b'}
    ],

    includeBefore: [
        {block: 'b'},
        {block: 'c'}
    ]
}

11 years ago

SevInf

Вместо forEach, я бы предложил метод query с DSL для запросов:

deps.query({block: 'a'}) - получить все непосредственные зависимости блока a. deps.query({block: 'b', tech: 'js']}) - получить все непосредственные зависимости блока b для его технологии js. deps.query({block: 'с', tech: 'js', full: true}) - получить полный граф зависимостей для блока c (включая зависимости его зависимостей и т.д.). TODO: придумать лучшее название параметру full.

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

11 years ago

arikon

@SevInf Про query() интересно, нужно больше подробностей и примеров использования.

Типовые задачи:

получить список зависимостей для сборки js (или любой другой технологии)
получить список bemhtml зависимостей для сборки js (собирать для клиента только нужные шаблоны)
получить полный список зависимостей для сборки css (к обычным прямым зависимостям добавляются зависимости других технологий от css)

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

11 years ago

SevInf

получить список зависимостей для сборки js (или любой другой технологии)

.query({tech: 'js'});

получить список bemhtml зависимостей для сборки js (собирать для клиента только нужные шаблоны)

.query({tech: {'js': 'bemhtml'}})

получить полный список зависимостей для сборки css (к обычным прямым зависимостям добавляются зависимости других технологий от css)

.query({tech: 'css', full: true}), если я правильно тебя понял.

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

Тут пока затрудняюсь хорошо ответить. Возможно, какой-то параметр вроде skip поможет:

.query({tech: 'ie.css', skip: {block: 'noie'}});

11 years ago

scf2k

получить список bemhtml зависимостей для сборки js (собирать для клиента только нужные шаблоны) .query({tech: {'js': 'bemhtml'}})

Не смог осмыслить почему так.

11 years ago

arikon

Посмотрел на deps-resolver из enb. Тестов на него нет, jsdoc минимальный, и комментариев по коду нет совсем.

Понять, как оно используется можно из кода технологии deps.js.

Особенности реализации:

захардкожено знание про BEViS (view, skin) вперемешку со знанием про БЭМ (block, elem, mods)
конструктор на вход получает объект levels, в котором в особом формате содержится информация обо всех файлах на всех уровня переопределения, участвующих в сборке
захаркожено знание про deps.js и deps.yaml файлы (if в коде в нескольких местах)
отсутствует реализация зависимостей по технологиям (нашёл про tech ровно один if)
файлы с зависимостями читаются во время добавления очередной декларации вызовом addDecl()

Есть ещё набор хелперов для работы с зависимостями в модуле lib/deps/deps.js.

Зависимости по технологиям реализованы в отдельной технологии bemdecl-from-deps-by-tech.

Идея там в том, что перебираются все файлы зависимостей из levels, и собираются все зависимости, где tech равна указанной в конфиге технологии sourceTech. Из этих собранных зависимостей собирается bemdecl.js файл, который потом используется в цепочке сборки bemdecl.js -> deps.js -> технология. Недостаток в том, что так не соберёшь все нужные css, например (как мы делали в bem-techs-core).

11 years ago

arikon

@SevInf

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

includeBefore не очень понятно. Что именно должно быть before, то что в списке ниже или то, к чему описываются зависимости? При этом include намекает на необходимость включения.

Может, лучше deps и priority? deps определяет зависимость от, а priority определяет только приоритет включения.

Чтобы задать и зависимость, и приоритет, нужно будет определить сущность в двух списках. Может, стоит предусмотреть дополнительное поле priority в сущностях, которые указываются в deps? И, если зависимость нужна раньше описываемой сущности, выставляем флаг priority: true. Примерно так сделано в deps.yaml в enb. Но отдельный список будет по-прежнему нужен для описания приоритета без включения зависимости.

11 years ago

arikon

@SevInf Добавил входной формат в issue description. Норм?

11 years ago

SevInf

priority мне тоже не очень нравится, особенно запись priority: true с толку сбивает. Может, лучше placeFirst? Неочевидности нет, ясно что то что в списке размещается сначала.

11 years ago

scf2k

priority мне тоже не очень нравится, особенно запись priority: true с толку сбивает. Может, лучше placeFirst? Неочевидности нет, ясно что то что в списке размещается сначала.

high-priority, foremost, primary, essential, important?

11 years ago

tadatuta

@veged в старой переписке предлагал orderedDeps/unorderedDeps.

замечания к этому варианты возникли такие:

не очевидно, почему ordered — это про то, что будет подключено до.
слово deps очевидно из того, что мы пишем это в файле deps.js и его можно опустить.

Еще варианты из переписки: precedingDeps (preDesp) / depsBefore / beforeDeps / priorDeps / aheadDeps / depsAhead (и они же без Deps)

link + linkBefore

11 years ago

arikon

@scf2k

high-priority, foremost, primary, essential, important

preceding

10 years ago

ilyar

Предложение priority должен иметь цифровое значение (0, 1, 2...10), если он не указан то вычисляется подобно тому как это сделано в xslt алгоритм вычисления задокументировать и при необходимости сделать возможным переопределять подобно тому как планируется сделать с правилом наименования.

10 years ago

tadatuta

@ilyar что будет означать, например, { priority: 4 }?

10 years ago