Решил предложить в качестве идеи на подумать такой вариант - https://yadi.sk/i/HLM1KIHIYexBG Заголовок - над подписью, подпись меньше и убрать решетку с номером непонятно чего ;)
Решил предложить в качестве идеи на подумать такой вариант - 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: [] // массив для указания приоритета зависимостей без их включения
}
Абстрактный класс, задаёт интерфейс для парсеров зависимостей.
Парсер исходных файлов deps.js
.
Парсер исходных файлов deps.yaml
.
Парсер исходных js
файлов, использующих модульную систему ym
. Полезен при условии, что имена модулей однозначно соответствуют описываемых в них БЭМ-сущностям.
Утилиты возвращают новый инстанс DepsContainer
с вычисленными зависимостями:
subtract(source, subtraction...)
merge(source...)
intersect(source...)
Analyze — пакет, который строит объектную структуру проекта. Первая цель — генерация UML-диаграмма классов и взаимодействий, которая бы не протухала.
Анализ структуры проекта и связей между ними.
Работает на провайдерах.
Подходит для BEViS-проектов, но сама структура не слишком завязана на BEViS, т.к. используются достаточно абстрактные сущности.
Но провайдер jsdoc работает на BT-шаблонах.
Есть провайдер для модульной системы, написанной dfilatov.
Есть дополнения.
CLI Единственная команда report — загружает конфиг .analyze.js (если есть), вынимает оттуда директории проекта, анализиует проект (все файлы с расширением js, но не test.js). Каждый файл обрабатывается отдельно.
Каждый провайдер возвращает данные, на основе которых формируется общий результат.
Пост-обработка — построение зависимостей (между классами).
Набор зависимостей — это отдельная сущность.
Обработка:
На данном эта получаем Объектная модель (инстанс Project) и инстанс ErrorLog (включает указание на строку с ошибкой)
Настройка 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 плохо, т.к. будет много копипаста. Так что нужно вынести куда-то общебэмовую функциональность:
Служебное низкоуровневое API (bem-util):
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