Open belozer opened 6 years ago
{ block : 'libA/chart' }
// bem-xjst
modules.define('libA/chart')
// ym
:block(libA/chart)
// post.css
{ block : 'libH/chart' }
// bem-xjst
modules.define('libH/chart')
// ym
:block(libH/chart)
// post.css
или так
{ block : 'libA.chart' }
// bem-xjst
modules.define('libA.chart')
// ym
:block(libA.chart)
// post.css
{ block : 'libH.chart' }
// bem-xjst
modules.define('libH.chart')
// ym
:block(libH.chart)
// post.css
Кажется, что достаточно исключить «лишние» блоки из массива https://github.com/enb/enb-bem-techs/blob/master/techs/files.js (если используется enb):
config.nodes( 'bundles/*', ( nodeConfig ) => {
nodeConfig.addTechs([
[techs.bem.levels, { levels: levels }],
[techs.fileProvider, { target: '?.bemdecl.js' }],
[techs.bem.deps, { target: '.?.deps.js' } ],
[techs.bem.files, { depsFile: '.?.deps.js' } ], // ← вот тут
]);
});
Зачастую библиотеки используют под капотом другие библиотеки в качестве зависимостей + есть еще вопрос версионирования. Поэтому мы остановились на том, чтобы самые частоиспользуемые блоки называть коротко и удобно.
@Realetive ну а что, если они не лишние? )
Неймспейсы для либ сами по себе выглядят как усложнение, потому что блоки и модули сами по себе уже неймспейсы. На мой взгляд правильнее было бы уметь фильтровать при интроспекции некоторые блоки в уровнях, либо публиковать отдельные библиотеки по каждому набору блоков.
Кажется, что достаточно исключить «лишние» блоки из массива
Тогда уж в результирующем таргете files, и это будет работать только для enb.
Опять же, если добить историю про нейминг на файловой системе типа lib1/button/button@desktop.js
то можно было бы фильтровать по маскам внутри уровней прямо в передавая опцию в walk
.
p.s. Предвкушая вопрос почему сейчас нельзя — сейчас обход прохардкожен в walk и кастомизировать его сложновато.
либо публиковать отдельные библиотеки по каждому набору блоков.
Сейчас стараюсь следовать этому способу. Но невозможно контролировать других разработчиков.
Подвяжу к обсуждениям ответ @vithar
не однократно поднимался вопрос про возможноть при подключении библиотке указывать префикс, с которым будут использоваться блоки этой библиотеки, типа { lib: 'bem-components', prefix: 'bem' } и потом использовать bem-button вместо button. В частности, написание стилей через :block(…) делает это более возможным. Но полностью это реализовать нетривиальная задача, с одной стороны, и не приоритетная — с другой.
Неймспейсы для либ сами по себе выглядят как усложнение
согласен
Зачем изобретать велосипед, можно использовать готовые инструменты и экосистему npmjs, они уже добавили неймспейсы. Чтобы не плодить репозитории (как это делают тут http://atlaskit.atlassian.com/packages), есть инструмент https://www.npmjs.com/package/lerna используется https://github.com/bem/bem-sdk, но это не про интерфейс, но есть и про него https://github.com/primer/primer и https://github.com/fyndiq/fyndiq-ui, и наверное есть еще.
Для совместимости с текущими инструментами, надо будет только прокачать технологию deps.js
, научить ее читать package.json
.
Поправка atlaskit тоже используют монорепозиторий https://bitbucket.org/atlassian/atlaskit-mk-2/src/master/ и видимо обходятся без lerna. Дока у них крутая, сбила с толку.
@ilyar проблема в том, что может быть 2 блока calendar
(с разной реализацией) в разных либах и они не должны ломать друг друга (в том числе через css
)
Кроме костылей (в виде префиксов) или Центрального Реестра Блоков
:) пока не понятно как добиться этого.
@belozer не понятна проблема, которую ты описываешь. Вот то о чем я говорю:
{
"name": "project"
"dependencies": {
"@belozer/bem-calendar": "1.0"
}
}
@ilyar
// libA/@common/button.bemhtml.js
block('button').content()((node, ctx) => ({ elem : 'text', content : ctx.text ))
// libA/@common/button.styl
.button
display: flex
// libB/@common/button.bemhtml.js
block('button').content()((node, ctx) => ctx.text)
// libB/@common/button.styl
.button
display: inline-block
Кажется понял, такая проблема, могла бы быть решена через общий интерфейс в PHP это реализуют виртуальные пакеты Composer, но в данном случаем сложно представить как можно было бы описать такой интерфейс.
Думаю чтобы попытаться решить появления похожих блоков (потенциально сдающих конфликты), самый простой путь Центральный Реестр Блоков
, именно так решали эту задачу в развитии jQuery плагинов, есть гайд и место размещения с начало был bower а потом перешли на npm.
И внезапно, для БЭМ-библиотек он тоже есть https://github.com/bem-contrib ему только не хватает крутой морды с гадом и рейтингом. И это правильный путь конкуренции и сотрудничества. Этот путь не возможен без поддержки, хотя бы до момента зарождения самоорганизации. Полагаю именно эту задачу решает лего внутри яндекса.
Путь одиночества и самобытности, сложный в начале и простота в использовании это добавить префиксов, интересная задачка, но, как по мне, есть более приоритетные.
@belozer Это реальная проблема или фантазия?
Поправка atlaskit тоже используют монорепозиторий bitbucket.org/atlassian/atlaskit-mk-2/src/master и видимо обходятся без lerna. Дока у них крутая, сбила с толку.
У них bolt, аналог lerna.
Про депсы из package.json мы уже местами начинаем думать локально и подбиваем клинья, преобразуя текущее Лего к монорепо, но пререквизитом является поддержка кастомных уровней в walk и преобразование схемы на fs от {layer}.blocks/{entity}.{tech}
к {entity}@{layer}.{tech}
.
Когда каждый блок будет лежать в своей папке — сильно проще из этих папок сделать отдельные модули и нагенерировать там же package.json
файлы, за счет чего и публиковать каждый блок отдельно в NPM.
package.json
в корне блока, правда, не решает задачу целиком, потому что будут еще и зависимости от элементов, но пока не понятно насколько это болит.
Но если даже каждый блок со всеми его элементами будет обладать общими зависимостями, то пока не решена проблема с честной модульностью блоков — и тогда вопрос с «неймспейсами» встаёт более остро, ведь будет возможность даже не желая того привезти один компонент двух разных версий в браузер, или не встаёт, если мы всё равно не хотим лишний код в браузере, и тогда можно будет для UI модулей просто не использовать NPM (?).
В общем, копать и копать).
p.s. А еще можно взять реакт с css-in-js ;-) и мучаться с другими проблемами, еще менее приятными).
ведь будет возможность даже не желая того привезти один компонент двух разных версий в браузер
это должен решить пакетный менеджер и семвер, если он не может решить, то
и тогда вопрос с «неймспейсами» встаёт более остро
в реальности это будет означать что одна либа не очень активно обновляет свои зависимости и уверен не правильно хотеть решить это «неймспейсами»
@component-namespace mine {
@component SearchForm {
padding: 0;
margin: 0;
@modifier advanced {
padding: 1rem;
}
@descendent textField {
border: 1px solid #ccc;
@when invalid {
border: 1px solid red;
}
}
}
}
Вот что есть про namespace
Using PostCSS with BEM and SUIT Methodologies by @kezzbracey
Имеются ли наработки (идеи развития) в сторону ограничений областей видимости для либ?
Например: В проекте используется либа libA с блоками A, B, C. На проекте есть блоки D, E, F
Но появляется интереcная либа libH.... С более проработанная реализация блоков E и F... Но в этой либе используются свои реализации блоков A и C.
Что в свою очередь порождает конфликт.
Хорошо было бы использовать что-то вроде namespace для блоков из либ. @vithar @veged @tadatuta @zxqfox