@ *.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]

@pvlv думаю лучше в issue репозитория писать, т.к. здесь другая тема вопроса ;)

[pvlv]

@tadatuta у меня "блок" ассоциируется с html-блоком

html без css - может существовать
css без html - нет, зависим от html

Получается, что html первичен - может существовать сам по себе(с некоторыми допущениями)
=> это сущность
=> блок ,
а css - не может существовать в отрыве от html
=> не может быть сущностью
=> не может быть блоком,
тоже самое касается картинок(они зависимы от html) и тд.

Что касается js, тут все иначе

js - не просто описание чего-то, это логика, он заимодействует с блоком, влияет на блок

Если мы добавим к блоку(с зависимостями -> css -> img) js файл - можно теперь блок называть "блоком"?

В React эту ситуацию разрулили так:

• компонент, который рендериться - "тупой" компонент, или просто компонент
• компонент, который имеет логику - "контейнер"

React component == React container // true
React component !== React container // true

от сюда следует

1. element == component == block == module == box == container // true
2. element !== component !== block !==module !== box !== container // true

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

соответсвует 1 выражению,
а 2ого выражения у БЭМа нет ввиду исторических особенностей

Считаю, что в текущих реалиях эту ситуацию нужно пересмотреть, взвесить все "за" и "против".
Возможно, скоректировать развитие БЭМа в сторону разработки среды(не бандлер, не методология, не раннер) для работы с подобными сущностями(у меня есть пару идей на этот счет, если интересно могу поведать о них). Но это уже другая история.

[pvlv]

@belozyorcev это был не вопрос, я просто акцентировал внимание

[belozer]

@pvlv

это был не вопрос, я просто акцентировал внимание

Если ты про именования репозитория, то акцентируй его и здесь ;) #157

а css - не может существовать в отрыве от html

А вот по поводу CSS ты немного заблуждаешься. Он существует и без HTML. Например для SVG, или, например в рабочем окружении GNOME используется CSS.

тоже самое касается картинок(они зависимы от html) и тд.

*:after { content: "", background: url('bem_image.png') }.
В html невозможно создать :after. Это псевдоэлемент, который создаёт именно CSS.

у меня "блок" ассоциируется с html-блоком

https://ru.wikipedia.org/wiki/Блок
Блок — в программировании: часть кода, которая воспринимается как единое целое.

upd
По поводу react ты прав. Они сделали просто шустрый view и всё. Единственно чем мне симпатичен React - это VirtualDOM (без него React не был бы так популярен ИМХО). Но мне воспринимать его сложнее, чем блоки в БЭМ. Вокруг БЭМ сложилась дурная репутация из-за того, что люди не так всё поняли, или пытались с ним работать пару лет назад. Также о БЭМ часто всегда узнают только через длиннющие CSS классы, а не о том, как стоить интерфейсы блокам. Или пробуют что-то сделать, а в проект внедрить не могут. Здесь я высказывал своё мнение по этому поводу #159

[pvlv]

А вот по поводу CSS ты немного заблуждаешься. Он существует и без HTML. Например для SVG

SVG - в отрыве html/xml не может существовать (контекст - вэб).

... или, например в рабочем окружении GNOME используется CSS.

Интересно, а как вы css будете рендерить? Там не html, но что-то(лень искать) на что влияет css.

Сделать background зеленым, которого нет. Это как?

*:after { content: "", background: url('bem_image.png') }.
В html невозможно создать :after. Это псевдоэлемент, который создаёт именно CSS.

А как же тег <img>? Учитывая ваше замечание, можно сказать, что "картинки имеют зависимость как от html, так и от css"(но это не меняет картины)

https://ru.wikipedia.org/wiki/Блок
Блок — в программировании: часть кода, которая воспринимается как единое целое.

А где я написал, что блок не является единым целым? Текст после обзаца объясняет, что я имею ввиду.

upd

Вокруг БЭМ сложилась дурная репутация из-за того, что люди не так всё поняли, или пытались с ним работать пару лет назад

Продать/объяснить можно все, что угодно. Вопрос в мотивации. До React`a у twitter была(и есть https://flightjs.github.io/) похожая идея, но не взлетело.

[belozer]

@pvlv

...но что-то(лень искать)

GTK+

А где я написал, что блок не является единым целым? Текст после обзаца объясняет, что я имею ввиду.

bemtree описывает структуру сущности? Да.
bemhtml преобразует сущность в html? Да.
css перекрашивает только эту сущность? Да.
js управляет только этой сущностью? Да.

Значит всё это зависимо и воспринимается как едино целое. Считаю дальнейшее обсуждение неуместным, т.к. оно уже ушло от темы. Но ты можешь создать issue на форуме и подробно всё описать.

[pvlv]

@belozyorcev

bemtree описывает структуру сущности? Да.
bemhtml преобразует сущность в html? Да.
css перекрашивает только эту сущность? Да.
js управляет только этой сущностью? Да.

Все верно это "блок", который состоит из bemhtml, bemtree, css, js

Примеры блоков

1. Блок
   bemhtml, bemtree, css
2. Блок
   bemhtml, bemtree, js
3. Блок
   bemhtml, bemtree, css, js

1. Блок == 2. Блок == 3. Блок

Они блоки и все, и поэтому они равны

Но

Если их стравнивать "строго"

1. Блок !== 2. Блок !== 3. Блок

, то они не будут равны

цель(Блок 1) != цель(Блок2) != цель(Блок3)

Другие примеры

• уже приводил пример с React
• в функционально программировании есть такие понятия как "чистые функции", "функции высшего порядка" и тд. Они все являются функциями, но для того, что бы лучше понимать их предназначение, используют термины(дополнительный уровень абстракции)
• и тд

Блоки блоками, но назначения/цели/задачи могут быть разными у этих блоков => они должны называться по разному

[belozer]

@pvlv в БЭМ тоже используют контейнеры. Это те блоки, которые состоят из блоков. Например блок page. Другое дело как именовать их. Можно например container-page. Всё зависит от разработчика, как ему удобней.

[tadatuta]

@pvlv

а css - не может существовать в отрыве от html
=> не может быть сущностью
=> не может быть блоком

Разве мы где-то утверждали, что CSS — это сущность или блок? Мы говорили все на той же странице про основные понятия БЭМ, что «блоки могут быть реализованы в одной или нескольких технологиях, например: поведение — JavaScript, CoffeeScript; внешний вид — CSS, Stylus, Sass; шаблоны — Pug, Handlebars, XSL, BEMHTML, BH; документация — Markdown, Wiki, XML».

Еще раз повторюсь: всякий раз, когда ты читаешь слово «блок» на bem.info, считай, что там написано «компонент». Именно такой смысл вкладывается в это слово. Это синонимы. Примерно как кекс и маффин ;)

[pvlv]

«блоки могут быть реализованы в одной или нескольких технологиях, например: поведение — JavaScript, CoffeeScript; внешний вид — CSS, Stylus, Sass; шаблоны — Pug, Handlebars, XSL, BEMHTML, BH; документация — Markdown, Wiki, XML»

моя цит.

Получается, что html первичен - может существовать сам по себе(с некоторыми допущениями)
=> это сущность
=> блок ,
а css - не может существовать в отрыве от html
=> не может быть сущностью
=> не может быть блоком,
тоже самое касается картинок(они зависимы от html) и тд.

и

Все верно это "блок", который состоит из bemhtml, bemtree, css, js
Примеры блоков
Блок
bemhtml, bemtree, css
Блок
bemhtml, bemtree, js
Блок
bemhtml, bemtree, css, js

@tadatuta А где я написал, что блоки должны использовать определенную технологию? Вместо этих вставьте другие.

---

Еще раз повторюсь: всякий раз, когда ты читаешь слово «блок» на bem.info, считай, что там написано «компонент»

цит. из моего коммента

element == component == block == module == box == container

Я это прекрасно понимаю. И наглядно показал.
@tadatuta Чему будет равно это выражение (вы умеете приводить "не строгому неравенству"). Подсказка - сначала к 1...)

@tadatuta А что быдет если мы будем "строго сравнивать"? И чему это выражение будет равно?

element !== component !== block !== module !== box !== container

цит.

Блоки блоками, но назначения/цели/задачи могут быть разными у этих блоков => они должны называться по разному

они(блоки) не равны между собой => (следовательно) => должны называться по разному для лучшего понимания происхоящего.

---

Примерно как кекс и маффин ;)

Яндекс - надменность

[belozer]

@tadutata я вот подумал... А может действительно нужно ввести понятие бокса или контейнера, как абстракцию над управляющим блоком? Чтобы блоки продолжали означать маленький компонент, а контейнер - наиболее полный компонент чтобы можно было понять где ветвь (контейнер), а где ягодки (блоки).

[belozer]

Например:

form-box - наш "основной" блок/компонент, который состоит из маленьких, примитивных блоков.

[pvlv]

в БЭМ тоже используют контейнеры. Это те блоки, которые состоят из блоков. Например блок page. Другое дело как именовать их. Можно например container-page.

@belozyorcev В БЭМе, должно быть четко прописано как должен именоваться подобный блок.

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

Раньше это не требовалось, но сейчас это важно.

---

Всё зависит от разработчика, как ему удобней.

Ага, и возвращаемся до БЭМ времена.

---

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

cпс тебе, именно это я имел ввиду

они(блоки) не равны между собой => (следовательно) => должны называться по разному для лучшего понимания происхоящего.

[tadatuta]

@pvlv

Я еще один последний раз попробую с аналогиями.

Есть тег <div>, а есть <iframe>. Если попытаться «сравнить» по твоей схеме, то, видимо:

<div> == <iframe> // true
<div> === <iframe> // false

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

Да, очевидно, что блоки могут быть разными. В той же степени, в какой Web Components могут быть разными. Но они при этом вполне могут продолжать называться веб компонентами.

[tadatuta]

@belozyorcev

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

Большинство блоков на практике могут быть контейнерами. И даже элементы зачастую контейнеры.

Давай возьмем простой пример со списком. Сегодня был блок list со списком (каждый айтем был листом), а завтра в элементы списка насыпали ссылок — элементы оказались контейнерами (теперь ссылки — листы). Послезавтра в ссылки добавили иконки и теперь ссылки тоже контейнеры, а листы — иконки. А тут оказалось, что иконки на SVG и нам нужно повлиять на какой-то вложенный в иконку узел.

К списку, его айтемам, ссылкам и иконкам вполне могут быть примиксованы другие блоки или элементы с богатым внутренним миром. Или наоборот, один блок может быть разнесен по нескольким несвязанным DOM-узлам.

А представь эту же историю на более серьезных примерах. Будем на каждый чих их переименовывать? Какую задачу это решит?

[pvlv]

@tadatuta,

<div> == <iframe> // true

потому, что div- это тег(1), iframe - это тег(1) =>тег == тег // 1 == 1

<div> === <iframe> // false

false, потому, что

div-тег(ЦЕЛЬ/НАЗНАЧЕНИЕ/СУТЬ - является блочным элементом и предназначен для выделения фрагмента документа с целью изменения вида содержимого)

iframe(ЦЕЛЬ/НАЗНАЧЕНИЕ/СУТЬ - является контейнером, содержание которого игнорируется браузерами)

Цель(div) !== Цель(iframe) // true

Поэтой причине div и iframe называются по разному, но при всем при этом они являются тегами(блоками)

А что будет если они будут называться одинаково?

// БЭМ сейчас
<div class="tadatuta tadatuta--mod"> // блок состоящий из блоков 
<div class="tadatuta2 tadatuta2_elem"></div> // блок
</div>

Или все таки лучше так ?

// Что я хочу от БЭМа
<div class="tadatuta tadatuta--mod"> // Блок, который является контейнером
- <div class="tadatuta2 tadatuta2_elem></div> // Блок, который является блоком
</div>

Пример:

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

А структура папок будет следующая(очень упрощенная) и это наглядный пример

/blocks
-- /tadatuta
----*.css
----*.js
----tadatuta.html
--/tadatuta2
----.*css
----.*js
----tadatuta2.html
/components
-- components.html // инклюдит в себя html/pug/nunjucks из блоков tadatuta и tadatuta2, не подключаем css и js идет в общий бандл(собираются gulp или webpack)
/app
- index.html / результат сборки
- *.css
- *.js

Итог сборки

index.html
-*.css
-*.js
// включает в себя
- components.html
-- include tadatuta.html
-- include tadatuta2.html
- another-components.html
-- include another-tadatuta.html
-- include tadatuta2.html

Компонент, как блок высшего порядка должен только включать блоки.

Компонент, могут быть вложенными.

Блоки могу существовать в отрыве от компонентов - тогда это называется статик блок (например)
и тд

Слово "компонент" можно заменить любым другим словом - box, container и тд.

Чтобы понять, что они отличаются, достаточно знать их названия.

Что бы знать название, нужно знать как называть. Пока везде блоки в блоках на блоках через блоки.

В БЭМе, есть только блок и все, а остальное додумайте сами. Это актуально было 5-10 лет назад, но не сейчас. БЭМ должен однозначно дать определение блокам, которые используется для ввода дополнительного уровня абстракции. Это нужно для единообразия в новых проектах.

можно придумать кучу дополнительных классификаций и запретить называть теги тегами

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

Да, очевидно, что блоки могут быть разными.

А если блоки разные, почему они называются одинаково?(см.выше)

[tadatuta]

@pvlv

А где я сказал, что блоки нужно запретить называть "блоками"?

Как, где? В этом самом треде:

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

или

понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов.

 

А если блоки разные, почему они называются одинаково?

А если <iframe> и <div> разные, то почему они называются одинаково тегами?

Блоки называются по-разному: блок my-cool-video-player и my-great-page-container. Но при этом и то и другое блоки (или компоненты).

Получается, что одинаковое название «тег» для <input> (не может быть контейнером) и <div> (может быть контейнером) не напрягает, а одинаковое название «блок» для <input class="input"> и <div class="my-container"></div> вызывает когнитивные затруднения?

В твоем примере, если внезапно потребуется внутрь блоков tadatuta и tadatuta2 вложить еще несколько блоков, а потом вложить что-то внутрь их чайлдов, ты будешь каждый раз удобно двигать их из папки в папку? А когда к ним будут примиксованы еще пяток сущностей?

[pvlv]

@tadatuta

В твоем примере, если внезапно потребуется внутрь блоков tadatuta и tadatuta2 вложить еще несколько блоков, а потом вложить что-то внутрь их чайлдов, ты будешь каждый раз удобно двигать их из папки в папку? А когда к ним будут примиксованы еще пяток сущностей?

Да не надо ни чего двигать,есть блоки и лежат в папочке /blocks. Блоки не изменны. Они просто есть. Нужно делать include в другие блоки - тем самым создавать новую сущность. Эта сущность должна комбинировать блоки, возможно иметь логику.

/blocks
- /block1
- /block2
- /block3

Теперь создаем компонент1(или box или container)

/blocks
- /block1
- /block2
- /block3
/components
- /component1
-- component1.html

структура component1.html

<div class="component1">
include '/block1/block1.html'
include '/block1/block2.html'
<div>

Создадим еще 1 компонент component2.html

/blocks
- /block1
- /block2
- /block3
/components
- /component1
-- component1.html
- /component2 // <- новый компонент
-- component2.html //

структура component2.html

<div class="component2">
include '/block1/block1.html'
include '/block1/block3.html'
include '/components/component2.html' // <- в компоненты можно инклюдить другие компоненты
<div>

А теперь предположим что нам нужно изменить в componet1.html
И что нам делать? Правильно, добавить block4 и сделать component3.html

/blocks
- /block1
- /block2
- /block3
- /block4 // <- новый блок
/components
- /component1
-- component1.html
- /component2 
-- component2.html
- /component3 // <- новый компонент
-- component3.html 

структура component3.html

<div class="component3">
include '/block1/block1.html'
include '/block1/block4.html'
include '/block1/block2.html'
<div>

и итоговый index.html будет выглядеть вот так

<html>
<heade></header>
<body>
include 'components/component1.html'
include 'components/component3.html'
include 'blocks/block3.html'
include 'components/component2.html'
</body>
</html>

А где я сказал, что блоки нужно запретить называть "блоками"?
Как, где? В этом самом треде:

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

понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов.

Тут я не правильно выразился, извиняюсь.

[awinogradov]

@tadatuta ты там держись ;)

Sent from my iPhone

On 31 Jul 2016, at 16:12, Ivan Pavlov notifications@github.com wrote:

@tadatuta

В твоем примере, если внезапно потребуется внутрь блоков tadatuta и tadatuta2 вложить еще несколько блоков, а потом вложить что-то внутрь их чайлдов, ты будешь каждый раз удобно двигать их из папки в папку? А когда к ним будут примиксованы еще пяток сущностей?

Да не надо ни чего двигать,есть блоки и лежат в папочке /blocks. Блоки не изменны. Они просто есть. Нужно делать include в другие блоки - тем самым создавать новую сущность. Эта сущность должна комбинировать блоки, возможно иметь логику.

/blocks

• /block1
• /block2
• /block3
  Теперь создаем компонент1(или box или container)

/blocks

• /block1
• /block2
• /block3
  /components
• /component1
  -- component1.html
  структура component1.html

include '/block1/block1.html' include '/block1/block2.html'

Создадим еще 1 компонент component2.html

/blocks

• /block1
• /block2
• /block3
  /components
• /component1
  -- component1.html
• /component2 // <- новый компонент
  -- component2.html //
  структура component2.html

include '/block1/block1.html' include '/block1/block3.html' include '/components/component2.html' // <- в компоненты можно инклюдить другие компоненты

А теперь предположим что нам нужно изменить в componet1.html И что нам делать? Правильно, добавить block4 и сделать component3.html

/blocks

• /block1
• /block2
• /block3
• /block4 // <- новый блок
  /components
• /component1
  -- component1.html
• /component2
  -- component2.html
• /component3 // <- новый компонент
  -- component3.html
  структура component3.html

include '/block1/block1.html' include '/block1/block4.html' include '/block1/block2.html'

и итоговый index.html будет выглядеть вот так

include 'components/component1.html' include 'components/component3.html' include 'blocks/block3.html' include 'components/component2.html' А где я сказал, что блоки нужно запретить называть "блоками"? Как, где? В этом самом треде:

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

понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов.

Тут я не правильно выразился, извиняюсь.

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

[belozer]

@pvlv
Просто нужно сразу было описать проблему и предложение. Ты начал с далёкого от темы и у нас много времени ушло на обсуждение чего-то далёкого от темы, не по существу. :)

А по поводу разбивки по контейнерам (мне больше нравится правда "box") нужно попробовать поработать таким способом. И если оно окажется удачным, то продвигать его в массы. Я сейчас сам занимаюсь оптимизациями разработки в таких направлениях, эксперементирую.

// БЭМ-БОКСЫ

Суть правда только в принципах разработки, но не в инструментах

[tadatuta]

@pvlv

Видимо, ты не смотрел, как мы рекомендуем генерировать HTML, если предлагаешь использовать инклюды. Это точно не лучший способ. Подробности можно найти тут.

[belozer]

@tadutata box можно воспринимать как конечный набор для пользователя. Вспомни как мы рекомендуем передавать данные между блоками. У нас есть родительский блок, который знает о своих дочерних блоках, дочерние блоки ничего не знают о родителе.

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

Объясняем человеку простоту блоков, что они ничего не могут самостоятельно и полностью независимы. И теперь нам поря собрать умный бокс/кейс, который знает зачем он нужен, знает, что ему нужно для своей работы (Знает о дочерних блоках и использует их API).

Бокс строит bemtree из дочерних блоков. А также конектит события между блоками.

Например такое дерево:

header-box
-- logo
-- list
-- button

header-box слушает события из блока button. После наступления события он вызывает API блока logo и блока list и что он ещё может сделать, так это отправить какие-то данные на сервер.

И ещё раз повторюсь. Мы всегда рекомендуем использовать именно такой подход для коннекта блоков. Но не всегда понятно, какой же блок является мостом/передатчиком.
Просто можно добавить рекомендации по именованию именно таких блоков. Чтобы разбить блоки на "глупых" (легко переносимые библиотеки) и "умных" (заточенных под нужды конкретного проекта).

[tadatuta]

@belozyorcev
Все-таки не совсем так.
Есть, казалось бы, тупой блок select. Он всего лишь контрол выбора какого-то значения для отправки на сервер, но в нем лежат блоки button и popup.
popup, казалось бы, еще тупее, но в нем могут лежать очень разные по сложности штуки, вплоть до огромных сложных форм. Но в нашем конкретном случае с select-ом там тупое menu.
Однако не настолько тупое, чтобы не быть контейнером для menu-item-ов. А они, при всей своей простоте, бывают разных типов и могут включать как просто текст, так и, скажем, блоки link, внутри которых окажутся блоки icon с svg внутри.

PS: А «умный» box внезапно окажется не родителем select-а, а миксом к нему.

[veged]

@pvlv давайте я сэкономлю всем кучу времени и сил, хотя, возможно, это покажется слишком грубым и категоричным (заранее извиняюсь) — мы НЕ будем переименовывать понятия Блок, Элемент и Модификатор, можно дальше не ломать копья по этому поводу

[veged]

@belozyorcev зачем нужны префиксы @? если их убрать, ничего не ухудшится

[belozer]

@veged Для явного обозначение уровней.

Если директория начинается с префикса @, то это название уровня/платформы, где лежат конечные блоки.

blocks/desktop
blocks/touch
blocks/my_level

blocks/@desktop
blocks/@touch
blocks/@my_level

Если их убрать, то не совсем понятно, почему на такой-то ступени иерархии группа блоков, а на такой-то директория уже обозначает блок.

Основная цель данного топика - сделать структуру стартового проекта чистой и понятной.

Ведь проще объяснить человеку, что:

Категории начинающиеся с @ обозначают название уровня/платформы и содержат в себе конечные блоки.

чем:

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

[veged]

повторюсь — по моему без @ всё вполне очевидно

[Yeti-or]

можно еще сделать как технологию

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

2016-08-03 12:31 GMT+03:00 Sergey Belozyorcev notifications@github.com:

@veged https://github.com/veged Для явного обозначение уровней.

Если директория начинается с префикса @, то это название
уровня/платформы, где лежат конечные блоки.

blocks/desktop
blocks/touch
blocks/my_level

blocks/@desktop
blocks/@touch
blocks/@my_level

Если их убрать, то не совсем понятно, почему на такой-то ступени иерархии
группа блоков, а на такой-то директория уже обозначает блок.

Основная цель данного топика - сделать структуру стартового проекта чистой
и понятной.

Ведь проще объяснить человеку, что:

Категории начинающиеся с @ обозначают название уровня/платформы и
содержат в себе конечные блоки.

чем:

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#158 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABur3MM3aYnlvCMvwBwwmStmuEFY7lIgks5qcF_8gaJpZM4JTsZi
.

[pvlv]

@veged прочитайте, пжл, внимательно все, что я написал. Речь не шла про переименование божественных "блоков". Если кратко, идея - добавить дополнительный уровень абстракции при формировании структуры проекта.

[belozer]

@pvlv слишком много текста чтобы это было явно понятно. Ты начал просто тему издалека. Чтобы дальше разговор был более конструктивен, предлагаю более явно пояснять/предлагать реализацию абстракции.