@ *.blocks -> blocks/*

[belozer]

Часто видно в проектах, что люди предпочитают именно такой стиль расположения блоков. Он добавляет один уровень иерархии, но при этом визуально выглядит намного аккуратней.

common.blocks
desktop.blocks
desing.blocks

blocks/common
blocks/desktop
blocks/desing

таже история и с *bundles.

upd. При этом сразу понятно, что всё находится именно в папке blocks, а не в папках, которые оканчиваются на blocks. Сейчас все лежит на одном уровне (папки блоков, папки бандлов, служебные каталоги) и не сразу понимаешь куда нужно лезть.

[veged]

.blocks это такая же «технология» как и .css, .js и остальные

[tadatuta]

https://ru.bem.info/forum/-233/

[belozer]

@veged .blocks воспринимается намного тяжелее, когда человек видит каталог. blocks - даёт понимание, что именно здесь лежат красоты БЭМ.

В приведённой @tadatuta ссылке указано, что была идея .lib, но её нет в реализации и правильно что bower грузит пакеты в libs/

Воспринимать .blocks как технологию это как погружение в фильме "Начало". Технология в технологии. А если был бы .lib то технологии - в технологии - в технологиях.

Мне как разработчику важна приятная структура проекта, которая будет не будет резать глаза.

[qfox]

У нас была немного другая идея про desktop/touch, она сродни старым технологиям .ie8, но мы думали что будет, если назвать это платформа, и добавить суффиксом/префиксом @desktop/@touch к названию файла. В этом случае уровней на проектах и в библиотеках станет сильно меньше, блоки будут распределяться не по платформам, а по смыслу, и код компонент для разных платформ будет находится более-менее в одном месте.

[veged]

@belozyorcev .lib нет только потому, что bower так не умеет ;-)

ничего плохого во «фрактальности» не вижу — наоборот, это пример хорошей комбинаторики, когда через небольшое количество базовых понятий выражается всё

агрументация про «резать глаза» очень субъективна, некоторым и отсутствие папок css/ и js/ в корне проекта глаза режет, а другие понимают идею за *.blocks и им норм

[belozer]

@veged также идея была такая

blocks-common
blocks-desktop
blocks-desing

или

blocks.common
blocks.desktop
blocks.desing

очень субъективна

Для этого я и создал issue для голосования.

[belozer]

это пример хорошей комбинаторики, когда через небольшое количество базовых понятий выражается всё

Это и усложняет процесс адаптации. Почему common.blocks, desktop.blocks? Куда глядеть, где править? С ходу у человека возникает ступор в осознании технологий. Для него был БЭМ, как Блок - Элемент - Модификатор, а не ТТТ -> Технология - Технология -Технология.

[belozer]

@veger что нужно для понятия "технология"? Почему нужно вводить .blocks, .bundles, *.lib?

[vithar]

Мне удобна структура в проекте, когда в корне лежат директории blocks и bundles, они группируют сущности.

Структура с desktop.blocks и common.blocks мне на проекте не удобна:

1) между этими директориями всегда что-то попадает в дереве файлов

2) у меня на проектах нет разделения на desktop и touch, делается адаптивная вёрстка через media query.

Идея про то, что .blocks это технология реализации блока проекта — забавная абстракция, но никакой практической пользы от неё не вижу.

[awinogradov]

Если я правильно понял @zxqfox, то я его поддержу) Кажется структура вида:

- blocks/
  - button
    - button.desktop
    - button.touch
    - button.css
    - button.js

Сильно упрощает хождение по проекту. Но если по-чесноку, то @belozyorcev ты и сейчас можешь это настроить ;)

[tadatuta]

Да, прямо сейчас нет проблемы использовать blocks вместо common.blocks. Но я так понимаю, что исходный вопрос о том, какой вариант предоставлять в project-stub как дефолтный.

Мне common.blocks нравится тем, что несет в себе дополнительное знание, которое могут использовать роботы. Впрочем, в существующих тулзах ничего на это знание не завязано.

[apsavin]

Речь же не о том, чтобы везде использовать blocks/* вместо *.blocks. Речь, как верно говорит @tadatuta, о дефолтном варианте. О варианте для новичков. Для тех, кто первый раз. Короче, я поддерживаю предложение в формате, который выше наглядно показал @awinogradov

[belozer]

Но если по-чесноку, то @belozyorcev ты и сейчас можешь это настроить ;)

@awinogradov в этом то и дело. Мне без разницы, т.к. я могу и так сделать. Вопрос о новичках. Я с БЭМ знаком около года (или больше). Поначалу дико было видеть в проектах сообщества отличную от Project-stub структуру (blocks/*). Как это так? Против течения люди идут?. Но прошло время и я сам к ней пришёл, т.к. проект выглядит чище и понятней.

Остальное уже описал выше. А @vithar более точно сформировал мою мысль.

[voischev]

Не надо никакого голосования, нужно просто настроить ;) Я по разному работал — нормально и так и так. А project-stub наверное не самое лучшее место что бы сразу делать проще. Кажется он еще и для демонстрации полной картинки про стек

[vithar]

Стаб как раз правильное место для проще, с него начинают.

[vithar]

Если очень хочется вариативность по платформам, то на мой взгляд button.css, button.desktop.css и button.touch.css лучше, чем предложение выше.

[voischev]

Ну ок. Я всегда думал иначе про стаб) нормально жил)

[belozer]

block/@desktop/block.css
block/@touch/block.css
block/block.css

а на мой взгляд так.

[vithar]

Это введение ещё одной сущности на пустом месте.

[belozer]

block/block.css
block/block.desktop.css
block/block.js
block/block.spec.js
block/block.bemtree.js
block/block.desktop.bemtree.js
...

[veged]

когда вы думаете, что платформы это технологии, вы не учитываете, что платформенных уровней переопределения может быть неопределённое количество — например, на Серпе есть deskpad для общего между десктопом и тачпадом, вмёрживать каждый раз такой уровень в новые технологии блока это «подрыв устоев»

проблема вида «я хочу всё про блок видеть в одном месте» правильно решается с помощью BEM IDE, добиться этого чисто на файловой системе невозможно и не надо пытаться

[veged]

@vithar

у меня на проектах нет разделения на desktop и touch, делается адаптивная вёрстка через media query

у тебя не используется bem-components? они не способны работать в таком режиме

[vithar]

@veged у меня в bem.info используется bem-components:

https://github.com/bem-site/bem.info/blob/master/.enb/make.js

Тема islands не используется.

[veged]

@vithar без тачёвого уровня bem-components не будут полностью тачёвыми

[vithar]

@veged то, что я использую — работает.

[qfox]

когда вы думаете, что платформы это технологии, вы не учитываете, что платформенных уровней переопределения может быть неопределённое количество

просто учитываем, поэтому остальные выводы ошибочны.

[belozer]

Можно также сделать что-то типо

levels-blocks/common
levels-blocks/desktop
levels-blocks/touch

или

levels/common.blocks
levels/desktop.blocks
levels/touch.blocks

[belozer]

А ещё есть гениальное src

src/common.blocks
src/desktop.blocks

[belozer]

Достоинства варианта с levels/*

• Между папками блоков ничего больше не влезает
• Сходно с ./enb/make.js, где мы прописываем уровень блоков
• Папки блоков продолжают использовать *.blocks
• Папка блоков выделена на фоне других каталогов и файлов проекта.

[awinogradov]

Я за src/*. Тысячи проектов используют эту директорию для хранения основного кода.

Sent from my iPhone

On 26 Jul 2016, at 19:39, Sergey Belozyorcev notifications@github.com wrote:

Достоинства варианта с levels/*

Между папками блоков ничего больше не влезает Сходно с ./enb/make.js, где мы прописываем уровень блоков Папки блоков продолжают использовать *.blocks Папка блоков выделена на фоне других каталогов и файлов проекта. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[vithar]

Мне нравится blocks/*

[veged]

если мы реально считаем, что существующее нужно менять, то тогда я тоже за blocks/{common,desktop,touch,touch-pad,touch-phone}

надеюсь это не вызовет волну недовольства у тех кто привык и просто использует не приходя в каждый «question» тикет

но мне лично кажется, что мы не на то время тратим :-(

[belozer]

@veged нужно тогда сообществу напоминать про данный вопрос (в телеграме, форуме, слаке и т.д.), чтобы как можно больше людей высказались/ или были уведомлены.

По поводу bem-core@v4 тоже не все восприняли на все 100% и это нормально.

П.Н. v4 - самый крутой релиз из которых я знаю.

[belozer]

blocks/{@common,@desktop,@touch,@touch-pad,@touch-phone} а как на счёт такого варианта?

[pvlv]

@veged Почему "блок" это технология? Я не понимаю зачем вводить(точнее поддерживать) дополнительные термины и понятия для того, что называется "соглашением".

[pvlv]

БЛОК-html + БЛОК-css == БЛОК БЛОК-html + БЛОК-css + JS != БЛОК

Блок в контексте css - ок, блок в контексте html - ок, но если мы добавим js, разве можно будет назвать это блоком? Считаю, что нужно отказаться от понятия "блок" при организации файловой структуры проекта. Сейчас есть более подходящий термин для этого - "компонент".

БЛОК-html + БЛОК-css + JS == КОМПОНЕНТ

2007 - 2013 объяснять идею "html-css-инкапсуляции" (создайте папочку "блок" и туда закиньте файлы) через "блок" было правильно, но на дворе 2016, понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов.

[pvlv]

Можно еще называть "блоки" - "контейнерами". В таком случае, нужно додумывать дополнительные уровни абстракции.

[vithar]

@pvlv читали ли вы методологию (http://ru.bem.info/methodology/)?

Вся суть БЭМа в том, что все технологии, использующиеся при реализации и описании блока — суть блок.

html + css + js + картинки + документация + тесты = блок

[pvlv]

@vithar а вы внимательно читали мой комментарий?

Вся суть моего комментария в том, что "блок" устаревшее понятия 5-10 летней давности, и использование это определения(соглашения ) при разработки современных веб-приложений не есть хороший выбор. У ангуляра - компоненты, ember - компоненты, у react - компоненты, у яндекса - блок. Ну ок.

"Вся суть БЭМа в том, что все технологии, использующиеся при реализации и описании блока — суть блок."

этой идеи почти 10 лет, что все крутиться вокруг "блока"

[belozer]

@pvlv не согласен с тобой. Тоже самое можно сказать и components === modules. Модули будут всегда, с того времени, как только их придумали. В БЭМ филисофия завязана на блоках blocks === components === modules.

В БЭМ главное понимать, что интерфейс состоит из блоков. Я не знаю никакой другой инструмент / методологию, который мог на столько точно описывать себя (блок). Всё что не могут описать - называют component или module.

Проблема БЭМ не в том, что "модули" называются "блоками", а в том, что инструменты сильно запутаны и нужно находить способы их упрощения в использовании.

в частности сейчас я предлагаю переиначить категории в проекте с *.blocks на

blocks/ - директория где хранятся блоки / уровни блоков blocks/@level - уровень с блоками blocks/@level/block - конкретный блок

А почему именно так - сверху всё описано в комментариях + примеры.

[tadatuta]

@pvlv «Кекс» — устаревшее понятие 5-10 летней давности и использование этого термина в пищевой промышленности тормозит саму промышленность. То ли дело «маффин»! И, разумеется, не «зефир», а «маршмеллоу»!

Слово «толстовка» безусловно не является хорошим выбором и следует использовать «свитшот». Заодно не забыть заменить «портки» на «чиносы», а «мокасины» на «топсайдеры».

«Блокнот»? Архаизм, который тормозит развитие целлюлозно-бумажной промышленности и его следует срочно заменить на «молескин»!

Что уж тут говорить про «разработчиков интерфейсов», когда совершенно очевидно, что чтобы отрасль развивалась их следует прямо в трудовой записывать в «хипстеры» ;)

[awinogradov]

Плюсую за хипстеров в трудовой:)

Sent from my iPhone

On 30 Jul 2016, at 20:13, Vladimir Grinenko notifications@github.com wrote:

@pvlv «Кекс» — устаревшее понятие 5-10 летней давности и использование этого термина в пищевой промышленности тормозит саму промышленность. То ли дело «маффин»! И, разумеется, не «зефир», а «маршмеллоу»!

Слово «толстовка» безусловно не является хорошим выбором и следует использовать «свитшот». Заодно не забыть заменить «портки» на «чиносы», а «мокасины» на «топсайдеры».

«Блокнот»? Архаизм, который тормозит развитие целлюлозно-бумажной промышленности и его следует срочно заменить на «молескин»!

Что уж тут говорить про «разработчиков интерфейсов», когда совершенно очевидно, что чтобы отрасль развивалась их следует прямо в трудовой записывать в «хипстеры» ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[blond]

Мне всегда нравилось считать, что блок первичен, а уровень это не коллекция блоков, а часть реализации блока.

Текущие файловые схемы не отражают эту идею.

Предлагаемый вариант c @platform как раз наоборот.

block/@desktop/block.css
block/@touch/block.css
block/block.css

@belozyorcev если интересна такая файловая система, давай обсуждать её реализацию bem-walk. Можно завести ишью ;)

Даже если она не будет использоваться в project-stub, bem-components и т.д., сможешь использовать её в своих проектах.

[pvlv]

@tadatuta ок Понятие "блок" не отражает всей сути(если мы говорим о структуре проекта), я предложил варианты.

У ангуляра - компоненты, ember - компоненты, у react - компоненты, у яндекса - блок

Как использовать БЭМ + Angular или React, как будет выглядеть структура проекта, а сборка? Как этот вопрос решили ребята из Яндекс.Диск?

[belozer]

@blond мне не приходилось ещё сталкиваться со сборкой для разных платформ. Возможно я мыслю примитивно на счёт уровней, но они очень помогают дробить блоки на коллекции блоков, чтобы не превращать всё в длиннющее полотно и скролить весь список в редакторе.

А вот по поводу реализации платформ - мне такая версия нравится, когда вариации платформ описываются сразу в блоке, а не на другом уровне. Но тут у меня мало опыта чтобы что-то заявлять в защиту предложенного варианта :)

[blond]

@blond мне не приходилось ещё сталкиваться со сборкой для разных платформ. Возможно я мыслю примитивно на счёт уровней, но они очень помогают дробить блоки на коллекции блоков, чтобы не превращать всё в длиннющее полотно и скролить весь список в редакторе.

@belozyorcev если поменять слово «уровни» на «директории», то я с тобой согласен :)

[belozer]

@blond ну нет ))) именно уровни/слои. Допустим я подключаю библиотеку блоков. И если она будет не на том уровне стоять, на котором она должна быть, то и результат сборки может получится неожиданный, ведь она может дополнять / переопределять какие-то блоки.

А так получается я дроблю блоки на мини-библиотеки, которые потом можно легко перенести с проекта в проект (просто скопировав библиотеку/уровень блоков), а не искать нужные блоки для создания библиотеки.

[tadatuta]

@pvlv

Понятие "блок" не отражает всей сути(если мы говорим о структуре проекта)

Раскрой подробнее, почему не отражает? С моей точки зрения, «блок» — это полный синоним слова «компонент» и их можно невозбранно © использовать друг вместо друга.

Например, если открыть главную страницу методологии, то в шапке мы можем прочитать такую фразу «Она позволяет создавать расширяемые и повторно используемые компоненты интерфейса».

Или вот в основных определениях: «Блок — логически и функционально независимый компонент страницы».

Ну и так далее.

[belozer]

@pvlv

Как использовать БЭМ + Angular или React

Адаптировать под базовый проект и назвать components для консистености https://github.com/awinogradov/react-bl

А вот у меня другая ситуация, я адаптирую модули / компоненты для БЭМ и называю их блоки.

Всё просто. Какая система в приоритете и рулит в проекте, так модули и называй.

[pvlv]

@belozyorcev спс, @awinogradov почему не назвать "react-bem-starter-kit" или "react-bem-boilerplate"... я просматривал репозитории в поисках БЭМ-проектов, вот этот не заметил