А что такое бананчик?

Иногда банан это просто — банан.

Банан неплох :+1:

А что по поводу всего остального?

По файловой структуре — все смешано, не очень понятно, что где и зачем. Нелогично хранить сущности по технологиям, это сильно выбивается.

Для страничек у вас целиковый jade — проще было бы иметь попиленные на кусочки блоки, рядом с ними css/js, информация по блоку. И часть блоков у вас бы не повторялась на каждой странице.

https://github.com/SilentImp/VacayKit/blob/master/source/stylus/subscribe-form/subscribe-form.styl#L28 html body .subscribe-form — а зачем каскад?

https://github.com/SilentImp/VacayKit/blob/master/source/stylus/contacts/contacts.styl#L16 — а тут тегов куча

Куда еще посмотреть?

https://github.com/SilentImp/VacayKit/blob/master/source/coffee/contacts/contacts.coffee#L15 — если я правильно понимаю логику, то такие инстансы должны создаваться под каждый блок на странице. А сейчас один на все.

https://github.com/SilentImp/VacayKit/blob/master/source/coffee/contacts/contacts.coffee#L11 — высокий риск поломки при тряске и перемещениях по страницам.

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

а зачем каскад?

Что бы не завивисть от очередности. Увеличил вес селектора дополнительно.

а тут тегов куча

А bem разве исключает полностью использование селекторов по тегу и каскад?

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

У нас «по условию» максимум 1 такой блок на странице. Какой смысл делать выборку которая априори 1 результат? Можно было бы вообще его в синглтон завернуть … но опять же зачем?

@iamstarkov Дело не в файрфоксе, дело в каком-то внутреннем редиректе при первом заходе и кешировании этого дела (надо 302 вместо 301).

/cc @tavriaforever @tadatuta

https://github.com/SilentImp/VacayKit/blob/master/source/coffee/contacts/contacts.coffee#L11 — высокий риск поломки при тряске и перемещениях по страницам.

а как в данном случае было бы лучше сделать?

По файловой структуре — все смешано, не очень понятно, что где и зачем. Нелогично хранить сущности по технологиям, это сильно выбивается.

А как лучше организовывать? Может есть ман или пример?

@SilentImp Работать не с дом нодами, а с вашими объектами, представляющими БЭМ-сущности (если я правильно понял логику). Т.е. работать не с $ .contact-form, которых на странице может быть 2 и более, а с объектом ContactForm, который специально создается под каждый блок на странице, и еще лучше — еще и связать явно через элемент или микс (в зависимости от логики, сложно сходу понять, что у вас там происходит).

А как лучше организовывать?

В идеале:

project.blocks/ # или common.blocks/
|→ contacts
| \→ contacts.styl
| \→ contacts.coffee
| \→ contacts.jade
|→ country
| \→ country.coffee
# etc....

Может есть ман или пример?

Ман: https://ru.bem.info/method/filesystem/ Пример (этот форум): https://github.com/bem/bem-forum

upd

Всякие модернайзеры и резеты — желательно тоже раскидать по блокам, чтобы не делать при сборке для них исключений и подключать через единый механизм.

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

У нас в данном случае и есть объект ContactForm. Но нам надо взаимодействовать с dom. И я не очень понимаю каким образом это предполагается делать без селекторов.

Или предполагается что то, что будет байндить объект и его состояния в dom? Как в случае с angularjs? Впрочем там по сути тоже атрибуты и селекторы, только инкапсулированные в движек ангуляра…

В идеале:

Понял, спасибо. Буду пробывать.

Всякие модернайзеры и резеты — желательно тоже раскидать по блокам, чтобы не делать при сборке для них исключений и подключать через единый механизм.

а вот тут — поподробнее, пожалуйста. У меня сейчас дли обработки чистого js/css, которые не вписались в bower, именно отдельные правила сборки.

@zxqfox к именованию и делению блоков на странице вопросы не возникают? Все хорошо?

upd и что с каскадом и селекторами по тегу. Я рассказал о своих соображениях, но это приемлемо? Или вы бы не рекомендовали ни того, ни другого?

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

Ничего постыдного тут нет, сходу понять это все достаточно сложно, но когда приходит понимание как, зачем и что предлагается делать, то начинаешь забывать о куче проблем классического подхода ;-)

У нас в данном случае и есть объект ContactForm. Но нам надо взаимодействовать с dom. И я не очень понимаю каким образом это предполагается делать без селекторов.

Само взаимодействие с дом лучше оставлять внутри классов, которые знают про этот дом. Т.е., если мы в шаблоне для контактов рисуем какие дом ноды, а в js работаем с ними — это позволяет нам брать всю папку блока и уносить в другой проект легко и непринужденно. А при желании — выносить в библиотеку и подключать её на нескольких проектах.

Или предполагается что то, что будет байндить объект и его состояния в dom? Как в случае с angularjs? Впрочем там по сути тоже атрибуты и селекторы, только инкапсулированные в движек ангуляра…

Технически, если грубо, то да, это в идеале. Но я еще про несколько блоков на странице говорил — неудобно же будет, если у вас несколько похожих форм, и они все через 1 сущность работают. Можете посмотреть как сделано в i-bem.js (https://ru.bem.info/technology/i-bem/2.5.0/i-bem-js/) — BEM.decl('block-x') — это суть class BlockX extends BEM, биндинги — это наличие класса i-bem на DOM-ноде + data-bem атрибут с {'block-x':{...}} параметрами (или без). И при загрузке все нужные инстансы инициализируются автоматически, так же есть отложенная инициализация. Вам все не нужно, если вас устраивает текущий стек, но какая-то часть может быть весьма полезна для понимания.

а вот тут — поподробнее, пожалуйста. У меня сейчас дли обработки чистого js/css, которые не вписались в bower, именно отдельные правила сборки.

Обычно мы решаем это через борщик, в нем есть препроцессинг и подгрузка файлов с нужного места на диске в получаемый. Это помогает так:

• Создаем блок-хелпер с одним js файлом
• В js-файле пишем: вставь суда файл такойто и путь до bower_components/modernizr/...

Дока: https://ru.bem.info/tools/optimizers/borschik/js-include/

В вашем случае, когда у вас coffee, если использовать такой подход, у вас часть блоков будет с coffee, часть с js, и надо будет это в сборке учесть. В остальном должно подойти. Вместо Борщика можно использовать симлинки — если вам не нужно заворачивать содержимое в какой-то скоуп и собираться на винде проект не будет, то почему нет? ;-)

к именованию и делению блоков на странице вопросы не возникают? Все хорошо?

Кроме того, что они в jade и достаточно сложно читать — в целом, годно. Вы всегда можете перераскидать стили функционал между блоками, это достаточно простая задача, когда общая канва приложения становится понятна. Один из скрытых плюсов при полном бэм-стеке ;-)

body > header .hamburger {

вот это ад

http://silentimp.github.io/VacayKit/content.html

блок team, элемент photo, как по мне лучше вынести блок человека в отдельный блок, так как то правильнее, чтоли team__photo ожидаешь фото команды, а не одного человека из команды, чтобы было типа teammate__photo

http://silentimp.github.io/VacayKit/fly.html

• в чём разница между .items и .items__list?
• я думал item будет тем, чем у тебя сейчас является item__element item крайне неудачное название для блока, тут всё надо переразбить на блоки форма items-subscribe сделана круто
• Почему в подвале блок project это же меню?
  • почему ты кстати в навигации не используешь списки?

http://silentimp.github.io/VacayKit/home.html

• сломанная какая-то страница, не скроллится
• не смог посмотреть, но в целом кажется, что если у тебя есть какая-то сущность item, то лучше её выносить в свой блок, чем в элемент другой сущности

http://silentimp.github.io/VacayKit/vacancy.html

• комментарий про сущности полностью относится и kits__kit
• items__header — аналог методу functionsв модуле packages если привести аналогию из npm-экосистемы

• too much deps in gulpfile
• try buildbranch for deploy

попробуй поразбивать на блоки в jade, так прикольнее — я не про бем-стек, я про реюзабельность и dry

styl: каскады это ад для меня =( (только если это не каскад для изменения элемента под модификатором)

не понял структуру папки source =(

Нелогично хранить сущности по технологиям, это сильно выбивается.

не соглашусь, если импе удобно, то почему нет?

Для страничек у вас целиковый jade — проще было бы иметь попиленные на кусочки блоки, рядом с ними css/js, информация по блоку. И часть блоков у вас бы не повторялась на каждой странице.

тут соглашусь, это прикольно. Только непонятно, как это делать с Jade-шаблонами

не соглашусь, если импе удобно, то почему нет?

Потому что неудобно таскать между проектами/страницами/библиотеками/рефакторить. Субъективно, конечно.

Только непонятно, как это делать с Jade-шаблонами

Разбиваем на блоки + делаем хелперы, парсим, заворачиваем в тот же bh.js или любой кастомный шаблонизатор на матчерах, генерируем js-код, профит.

А bem разве исключает полностью использование селекторов по тегу и каскад?

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

Потому что неудобно таскать между проектами/страницами/библиотеками/рефакторить. Субъективно, конечно.

Потребителю кода и блоков (в данном случае, Импе) скорее всего лучше знать, как он будет использовать свои блоки.

Только непонятно, как это делать с Jade-шаблонами

Разбиваем на блоки + делаем хелперы, парсим, заворачиваем в тот же bh.js или любой кастомный шаблонизатор на матчерах, генерируем js-код, профит.

bh.js, кастомный шаблонизатор? у меня есть собственный воркфлоу, почему ты навязываешь свой и свои инструменты? это неудобно и не конструктивно, серьёзно

как он будет использовать свои блоки.

Это не исключает разрозненности шаблонов, js и стилей, которые, при том же рефакторинге, будут лежать в нескольких разных местах. Т.е. куча проблемы с такой структурой. Из плюсов — отсутствие сборки, но в наше время сборка почти всегда есть.

bh.js, кастомный шаблонизатор? у меня есть собственный воркфлоу, почему ты навязываешь свой и свои инструменты? это неудобно

Навяжи свои ;-) Кастомный шаблонизатор это не мой воркфлоу. Ты спросил — я ответил, и я ничего тебе не навязывал. И я не представляю, как ты иначе, такой умный, сможешь раскидать шаблоны и применить к нужным веткам bemjson или любого другого вью-ориентированного дерева. С удовольствием послушаю.

А как лучше организовывать?

базовое правило — стараться хранить сущности в одном месте: css, js и картинки ближе к самому блоку

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