А вы не могли бы отревьюить проект с bem-именованием?

SilentImp commented 9 years ago

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

https://github.com/SilentImp/VacayKit — репозиторий. http://silentimp.github.io/VacayKit/ — проект собран в gh-pages

Интересуют комментарии по поводу всего. И bem. И сборщика. И скриптов. И бананчика.

С уважением. Антон.

qfox commented 9 years ago

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

SilentImp commented 9 years ago

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

qfox commented 9 years ago

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

SilentImp commented 9 years ago

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

qfox commented 9 years ago

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

Для страничек у вас целиковый 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 — а тут тегов куча

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

qfox commented 9 years ago

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

qfox commented 9 years ago

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

iamstarkov commented 9 years ago

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

SilentImp commented 9 years ago

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

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

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

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

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

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

qfox commented 9 years ago

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

/cc @tavriaforever @tadatuta

SilentImp commented 9 years ago

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

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

SilentImp commented 9 years ago

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

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

qfox commented 9 years ago

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

qfox commented 9 years ago

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

В идеале:

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

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

SilentImp commented 9 years ago

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

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

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

SilentImp commented 9 years ago

В идеале:

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

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

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

SilentImp commented 9 years ago

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

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

qfox commented 9 years ago

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

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

У нас в данном случае и есть объект 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 и достаточно сложно читать — в целом, годно. Вы всегда можете перераскидать стили функционал между блоками, это достаточно простая задача, когда общая канва приложения становится понятна. Один из скрытых плюсов при полном бэм-стеке ;-)

iamstarkov commented 9 years ago

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-экосистемы

iamstarkov commented 9 years ago

too much deps in gulpfile
try buildbranch for deploy

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

iamstarkov commented 9 years ago

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

iamstarkov commented 9 years ago

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

iamstarkov commented 9 years ago

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

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

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

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

qfox commented 9 years ago

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

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

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

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

iamstarkov commented 9 years ago

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

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

iamstarkov commented 9 years ago

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

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

iamstarkov commented 9 years ago

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

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

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

qfox commented 9 years ago

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

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

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

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

iamstarkov commented 9 years ago

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

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

qfox commented 9 years ago

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

iamstarkov commented 9 years ago

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

не хочу никому ничего навязывать.

И я не представляю, как ты такой умный, … к нужным веткам bemjson

я не такой умный, и я не хочу bemjson, можно?

iamstarkov commented 9 years ago

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

это моё правило, моё ощущение бэма, как блоков и так далее. Я не понял как это мешает, это вроде как и есть бэм-файловая-структура, нет? знаю про опыт, у меня тоже немного есть

qfox commented 9 years ago

не хочу никому ничего навязывать.

Но ведь себе (и тем людям, которые работают с твоим кодом) ты уже навязал, так? Ты или один работаешь?

я не такой умный, и я не хочу bemjson, можно?

Реактовые шаблоны — та же история с вью-ориентацией, те же проблемы. XML/HTML-based — -//-. Web Components...

О чем ты споришь?

qfox commented 9 years ago

это моё правило, моё ощущение бэма, как блоков и так далее. Я не понял как это мешает, это вроде как и есть бэм-файловая-структура, нет? знаю про опыт, у меня тоже немного есть

К сожалению, ощущения ничего не объясняют. Я привел аргументы с обеих сторон, выбор очевиден, если есть этап сборки.

iamstarkov commented 9 years ago

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

посмотри исходники getbem и csssr-profile у меня в профиле, я постарался их по бэму запилить

iamstarkov commented 9 years ago

@SilentImp Работать не с дом нодами, а с вашими объектами, представляющими БЭМ-сущности (если я правильно понял логику). Т.е. работать не с

i-bem хорош, как абстракция, но нигде кроме яндекса не взлетел =( но идея прикольная

qfox commented 9 years ago

но нигде кроме яндекса не взлетел =(

У нас взлетел :-)

iamstarkov commented 9 years ago

В идеале: [тут пример файловой структуры]

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

iamstarkov commented 9 years ago

У нас взлетел :-)

и у мануфактуры, окей, теперь три + может быть десяток неизвестных компаний используют i-bem. успех

iamstarkov commented 9 years ago

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

:+1:

iamstarkov commented 9 years ago

борщик

он зафрижен и не развивается. зачем его советовать? есть куча npm-модулей, которые делают это всё куда круче

iamstarkov commented 9 years ago

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

qfox commented 9 years ago

успех

@iamstarkov Ну судя по твоей реакции, понимания пока нет. Будет ли — непонятно.

он зафрижен и не развивается. зачем его советовать? есть куча npm-модулей, которые делают это всё куда круче

Предложил бы хоть что-то ;-) Я не понимаю, почему не могу посоветовать инструмент, который работает. И то, что в него нет коммитов — не значит, что он зафрижен. Это значит, что нет багов и фич-реквестов. Зачем выдавать белое за черное — не понимаю.

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

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

qfox commented 9 years ago

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

.

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

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

Потому что по технологиям — это разбивка. Как сейчас у топик-стартера.

upd

Не соглашусь, что это возмутило меня ;-)

iamstarkov commented 9 years ago

@iamstarkov Ну судя по твоей реакции, понимания пока нет. Будет ли — непонятно.

я запутался. понимания чего?

iamstarkov commented 9 years ago

Предложил бы хоть что-то ;-)

150 тысяч нпм-пакетов, научиться пользоваться поиском несложно

Я не понимаю, почему не могу посоветовать инструмент, который работает.

можешь.

И то, что в него нет коммитов — не значит, что он зафрижен. Это значит, что нет багов и фич-реквестов.

он зафрижен, не потому что нет коммитов, а потому что его не будут развивать и отнюдь не потому что нет багов.

iamstarkov commented 9 years ago

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

1) я не спрашивал, а только рассказывал и обсуждал. 2) предлагаю не закрыть тему, а перенести её и только.

iamstarkov commented 9 years ago

Но ведь себе (и тем людям, которые работают с твоим кодом) ты уже навязал, так? Ты или один работаешь?

у меня аллергия на навязывание

qfox commented 9 years ago

я запутался. понимания чего?

Зачем вообще нужен был bemjson или почему реакт выглядит так, как выглядит. Или почему Web Components сделаны так, как сделаны.

Этот промежуточный view-ориентированный слой (реализованный в т.ч. с помощью bemjson) очень упрощает жизнь при работе над проектом. Допустимо его опускать в случае однодневных страничек, но если проект живет продолжительное время — оно спасает от кучи проблем.

150 тысяч нпм-пакетов, научиться пользоваться поиском несложно

Спасибо, т.е. альтернативы нет?

он зафрижен, не потому что нет коммитов, а потому что его не будут развивать и отнюдь не потому что нет багов.

Опять же, если его не будут развивать сейчас — это не значит, что завтра ситуация не изменится. И это не меняет того факта, что инструмент просто работает, решает свою задачу и нет смысла его развивать. Как много коммитов делается в find, ls или grep? Ты перестанешь пользоваться этими инструментами, когда узнаешь, что они «зафрижены»?

1) я не спрашивал, а только рассказывал и обсуждал. 2) предлагаю не закрыть тему, а перенести её и только.

Очевидно, что это бесполезно.

у меня аллергия на навязывание

Я не медик, но кажется, что это называется паранойя, а не аллергия ;-)

iamstarkov commented 9 years ago

Зачем вообще нужен был bemjson или почему реакт выглядит так, как выглядит. Или почему Web Components сделаны так, как сделаны.

я знаю, зачем он, как появился, как его использовать и использовал, какие плюсы и минусы. Но также я не могу закрывать глаза, что bemjson очень узкий инструмент, в том плане, что трата ресурсов на его изучение и внедрение не оправдываются, так как он так и не стал сколько бы то распространённым за 5 лет (хотябы на уровне handlebars, или jade).

если проект живет продолжительное время — оно спасает от кучи проблем.

большие проекты других компаний живут на других стеках и чувствуют себя хорошо — никаких особых профитов от bemjson нет

bem-site / bem-forum-content-ru

А вы не могли бы отревьюить проект с bem-именованием? #388