bem-sdk-archive
Support platforms inside block folder
block/@desktop/block.css
block/@touch/block.css
block/block.css
@blond ;)
I think we should create new scheme which will support platforms.
I don't want to add this logic in nested scheme.
Предлагаю вместо специального разделителя строго типизировать суффиксы:
entityName[.planform].techName
Этот путь мене походит на костыль, чем добавление спорного разделителя.
Из обсуждения в Telegram есть возражения:
@vithar: лучше всё же использовать разные сепараторы для платформы и технологии иначе будет невозможно отличить одно от другого...
__ и — это разделители между разными сущностями. А точка используется для отделения имени технологии от имени сущности и для разделения слов внутри имени технологии. Никаких зарезервированных слов сейчас нет и bem-naming или bem-fs-scheme очень простые модули, которые оперируют переданными разделителями. Ты предлагаешь ввести список зарезервированных слов и усложнить логику работы с именем технологии.
К примерам "разделения слов внутри имени" можно отнести .deps.js и .post.css это разделения костыли для простоты, избавляющие от дополнительных действий по настройки подсветки в редакторе.
Думаю будет не слишком большой список, если состарить список специальных расширений (т.н. зарезервированных слов), наличие такого списка нивелирует проблему сложности отличить одно от другого.
@ilyar Перечитал несколько раз так и не понял как ты хочешь решать подсветку в редакторе и чем не нравится @ как разделитель. Сейчас логика простая — всё после первой точки это технология, всё после последней — расширение. Плюс в твоем случае в том, что tech = extension, и нам это понятие будет не нужно, но у нас все инструменты на это завязаны по разным причинам (в т.ч. и по причине подсветки в редакторах), и если делать как ты предлагаешь, то нужно будет эти мелочи решать заново.
Я предлагаю добавить строгости и сказать есть extension = tech у которых могут быть алиасы (для упрощения работы в редакторах):
entityName.deps === entityName.deps.js entityName.pcss === entityName.post.css (расширение *.pcss не я придумал, например его продукты JetBrains поддерживают)
Еще есть у нас расширение *.ie8.css на данный момент это технология, но это про платформу, но по не известной мотивации мы решили на это не обращать внимание и втулить собаку, выглядит ровно также как собака в PHP, может это мое личное и испорченное восприятие.
Еще для примера давайте взглянем на хорошо известный нам подход к архивам file.tar.gz, а что если так [email protected].
В общем я не предлагаю сильно менять то что есть, а просто добавить немного порядка и общего смысла. В этом прядке, определять платформу станет возможным.
Я понятно объясняю?
Еще уточню, что знание про алиасы или специальный словарь использовать в реализации детекта сущности и ее технологии (при этом не меняется текущее использование .deps.js, .post.css).
Снаружи будет простой и прозрачный интерфейс entityName[.planform].techName.
@zxqfox http://sketchapp.me/scaled-export-masshtabirovannyj-eksport-dlya-ios/ вот тут (в iOS) тоже используют собаку и не морщатся, и, округляя, тоже для платформы
Как по моему так это слабый аргумент.
Сейчас entityName[.techA].techB, допустим разделитель собака т.е. entityName[@platform].techA].techB и возьмем например entityName.ie8.css получается [email protected], еще в дереве проекта это будет сортироваться так:
entityName.css
entityName.js
[email protected]
[email protected]
Как смотрится хорошо?
По мне так не очень.
@ilyar Скорее, [email protected]
p.s. Всё после первой точки это технология, инструменты не умеют [.techA].techB
[email protected] т.е. будет подразумеваться что [email protected]? Не ужели такое бывает?
Всё после первой точки это технология, инструменты не умеют [.techA].techB
Тут смотрел https://github.com/bem-sdk/bem-walk/blob/master/test/schemes/flat/techs.test.js#L35-L47 разве это не умение?
Полагал, что если исходить из entityName[.planform].techName получим:
entityName.css
entityName.desktop.css
entityName.etc.css
entityName.etc.js
entityName.ie8.css
entityName.js
и возможность собирать бандлы desktop, ie8, etc (примерно, понятно что это уже за рамками текущей либы).
Мне норм оба варианта: [email protected], [email protected] (сейчас у нас entityName.ie8.tech и мне он не норм).
Еще один минус схемы без доп. символа это сортировка:
С точками: С собакой:
entityName.css entityName.css
entityName.desktop.css entityName.js
entityName.etc.css [email protected]
entityName.etc.js [email protected]
entityName.ie8.css [email protected]
entityName.js [email protected]
@vithar ты распиши полный набор всех технологий в плоский список для 3х платформ хотя бы, а потом пиши свое буэ ;)
Это чудесно, но было полезно увидеть обоснование к буэ) Или это просто личное ощущение?
Думаю, что надо делать так:
# Схема с суффиксами
entityName/entityName.css
entityName/entityName.js
entityName/[email protected]
entityName/[email protected]
entityName/[email protected]
entityName/[email protected]
# Схема с папками
# (ну или без @, но тогда есть вопросы как определять что это платформа, а не хрень)
entityName/entityName.css
entityName/entityName.js
entityName/@desktop-ie8/entityName.css
entityName/@desktop/entityName.css
entityName/@touch/entityName.css
entityName/@touch/entityName.js
С элементами и модификаторами норм?
# Схема с суффиксами
entityName/entityName.css
entityName/entityName.js
entityName/[email protected]
entityName/[email protected]
entityName/[email protected]
entityName/[email protected]
entityName/_mod/entityName_mod_val.css
entityName/_mod/entityName_mod_val.js
entityName/_mod/[email protected]
entityName/_mod/[email protected]
entityName/__elem/entityName__elem.css
entityName/__elem/entityName__elem.js
entityName/__elem/[email protected]
entityName/__elem/[email protected]
entityName/__elem/[email protected]
entityName/__elem/[email protected]
entityName/__elem/_mod/[email protected]
entityName/__elem/_mod/[email protected]
# Схема с папками
entityName/entityName.css
entityName/entityName.js
entityName/@desktop-ie8/entityName.css
entityName/@desktop/entityName.css
entityName/@touch/entityName.css
entityName/@touch/entityName.js
entityName/_mod/entityName_mod_val.css
entityName/_mod/entityName_mod_val.js
entityName/_mod/@touch/entityName_mod_val.css
entityName/_mod/@touch/entityName_mod_val.js
entityName/__elem/entityName__elem.css
entityName/__elem/entityName__elem.js
entityName/__elem/@desktop-ie8/entityName__elem.css
entityName/__elem/@desktop/entityName__elem.css
entityName/__elem/@touch/entityName__elem.css
entityName/__elem/@touch/entityName__elem.js
entityName/__elem/_mod/@touch/entityName__elem_mod_val.css
entityName/__elem/_mod/@touch/entityName__elem_mod_val.js
Схема с суффиксами вообще монструозно выглядит же. А вас не смущает вот это повсеместное дублирование сущностей?
в виде сырого вброса:
# Схема с папками
entityName/#.css
entityName/#.js
entityName/@desktop-ie8/#.css
entityName/@desktop/#.css
entityName/@touch/#.css
entityName/@touch/#.js
entityName/_mod/#_val.css
entityName/_mod/#_val.js
entityName/_mod/@touch/#_val.css
entityName/_mod/@touch/#_val.js
entityName/__elem/#.css
entityName/__elem/#.js
entityName/__elem/@desktop-ie8/#.css
entityName/__elem/@desktop/#.css
entityName/__elem/@touch/#.css
entityName/__elem/@touch/#.js
entityName/__elem/_mod/@touch/#_val.css
entityName/__elem/_mod/@touch/#_val.js
где # — как раз про то, что уже написано в структуре
Голосую за схему с папками по платформам.
Если прятать платформу в папку с модификатором — наглядность очень сильно страдает имхо.
