Переходим на сторону сервера с bem-express

[vasIvas]

Все бы статьи так оформлялись, просто загляденье. Но к сожалению, это не делает вышеописанное понятным. Такое ощущение, что это внутренности монстра из прошлого, а не то что использует аж сам Альфа-Банк.
Удивился, если бы увидел завтра статьи на тему — «прощай angular, здравствуй бэм», " бэм vs react", «создателя redux уличили в подготовки покушения на создателя бэм»… Жуть…

[tadatuta]

Удивился, если бы увидел завтра статьи на тему — «прощай angular, здравствуй бэм», " бэм vs react", «создателя redux уличили в подготовки покушения на создателя бэм»

На самом деле всё чуть-чуть иначе: БЭМ в симбиозе с React, мастер-класс по внедрению возможностей БЭМ в проекта на redux и так далее.

А что именно осталось непонятным после прочтения статьи? Мы бы с удовольствием дополнили и/или упростили.

[justboris]

Я бы назвал это немного иначе: это не БЭМ в симбиозе React, а попытка использовать React при куче легаси кода, написанного на i-bem и других внутренних технологиях.

[tadatuta]

Борис, «по ссылкам не ходи @ комментарий пиши»?
Там ровно ноль связи с i-bem и каким-либо легаси ;)

[justboris]

Допустим, легаси в виде кода там нет. Но легаси образ мышления некоторых разработчиков все равно присутствует.

[dima117]

Ваша логика восхитительна! Поставил вам плюс в карму)

[i360u]

Только я не понял к чему все эти восторги? Куча специфичных зависимостей, жесткая привязка к спорному тул-чейну без надежды на относительно безболезненную миграцию в будущем, ради чего? БЭМ в CSS — не нужен, потому что есть ShadowDOM как и более легковесные принципы именования, применимые в современной компонентной разработке. БЕМ как шаблонизатор — это жуткий монстр… Половина статьи посвящана получению данных и вообще не связана именно с БЭМ. Что я упускаю, где та "жемчужина" ради которой я отвернусь от своего любимого стека и посмотрю в сторону БЭМ?

[ArVaganov]

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

Можно поподробней, пожалуйста? Тоже использую другой стек (React/Vue + immutable state), но что касается наименования классов в template/jsx кроме БЭМ не встречал более менее адекватных стандартов. Интересно было бы почитать. Что касается самой системы БЭМ, в полном ее понимании, и разумности ее применения – имхо это специфика разработки в большой корпорации, у них там на все заготовленные 'бест-практикс' готовые блоки/модули компоненты в целом и пр. Тем кто хочет идти работать в Y, думаю, точно стоит вчитаться и попробовать сделать проект по этой статье. Недавно была статья как они внедряют новые фичи в свои ресурсы, берут из базы подобный компонент, модифицируют, тестируют делают ревью, добавляют в базу компонентов и потом ставят на прод. Возможно тут с БЭМ действительно получается быстрее.

[vintage]

Мы используем что-то типа облегчённого БЭМ.

Там, где в БЭМ будет:

.my-app__menu > .mol-page__head {}

У нас будет просто:

[my_app_menu_head] {}

То есть каскад вообще не требуется. Генерится такой атрибут автоматом на основе дерева компонент. То есть дом-дерево будет сгенерено примерно такое:

<div my_app mol_book mol_view>
    <div my_app_menu mol_page mol_view>
        <div my_app_menu_head mol_page_head mol_view>

Из вот такого вот исходника:

$my_app $mol_book
    pages /
        <= Menu $mol_page

Это позволяет задавать стили для компонент (mol_page, например), для их элементов (mol_page_head, например), для элементов компонент, которые сами выступают в роли элементов других компонент (my_app_menu_head, например) и так далее до любого уровня вложенности компонент (my_app_menu_head_close_icon_path, например).

[vintage]

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

[Akuma]

А все же, стало интересно. Почему именно атрибуты, а не классы?

[vintage]

Модификаторы удобно засовывать в значения атрибута:

<div my_button="big accent">

[my_button] { ... }
[my_button~="big"] { ... }
[my_button~="accent"] { ... }

Хотя, у нас эта возможность пока и не используется. :-)

[knotri]

Так Css Modules и всякие там StyledComponent.
Считаю что бэм не нужен.

[kashey]

Есть HTML driven by CSS — это BEM, где у вас нет проблемы с CSS, но все остальное пляшет под его дудку
Есть CSS driven by CSS — это Tachyons/Turrent и другой atom/functional CSS. Где CSS-а практически нет, зато в html.

<button class="bg-purple f6 br3 ph3 pv2 white hover-bg-light-purple">

И есть CSS-in-JS/ShadowDOM который разными путями немного исправляет генетику CSS+HTML и к нему следует применять немного другие подходы, потому что НЕ нужно именовать что либо по BEM-методолигии так как нет _необходимости_.

>Тем кто хочет идти работать в Y, думаю, точно стоит вчитаться и попробовать
В Яндексе есть много мест где никакого БЕМа нет.

[vintage]

НЕ нужно именовать что либо по BEM-методолигии так как нет необходимости

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

[kashey]

Но функции, классы и переменные вы по БЕМу(и венгерской нотации) не называете?
Декомпозиция и изоляция — вечные друзья и спутники программиста.

[vintage]

Ещё как называю :-) Благодаря этому как раз и работает автоматическое детектирование зависимостей без портянок import/export.

[kashey]

А в bem-react так вообще импорты вычисляемые…

[vintage]

Это как?

[kashey]

import BlockElem from 'b:block e:elem m:modName';

github.com/bem/webpack-bem-loader

[vintage]

Зачем такие сложности?

[kashey]

Но это же лучше чем там -> в статье наверху?

[vintage]

Чем лучше?

[kashey]

Я уже год как не Яндексоид, и мне как-то и то и другое не очень.

[DarthVictor]

Благодаря этому как раз и работает автоматическое детектирование зависимостей без портянок import/export.

Рискну предположить, что заодно и без автокомплита и перехода к определению по Cmd+Click.

[vintage]

Да нет, всё работает благодаря тайпскрипту.

[DarthVictor]

А тайпскрипт как работает без импортов/экспортов?

[vintage]

Как положено он работает.

[vintage]

BEMDECL. Определяет список БЭМ-сущностей для страницы.
DEPS. Определяет зависимости между БЭМ-сущностями, которые разнесены по файловой структуре проекта и не отражены в декларации.

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

Изучающие БЭМ порой забывают о декларативности технологий и недоумевают: почему для описанного в шаблоне блока, не собираются его стили и скрипты. когда вы описываете шаблон (BEMHTML или BEMTREE) с каким-то блоком внутри (дочерний узел), вы просто добавляете новый HTML-элемент. Чтобы стили и скрипты этого блока попали в сборку, необходимо описать зависимость от него.

Зачем вообще вручную рулить всеми этими зависимостями, если можно подтягивать их автоматически по факту использования? Например, у нас стоит только воспользоваться где-нибудь в своём приложении компонентом $foo_bar, то автоматически будут подключены все стили/скрипты/шаблоны/остальное из директории /foo/bar. А если оной не окажется, то она может быть автоматически склонирована с гитхаба, если есть соответствующий маппинг в общем реестре. То есть вот это вот не нужно делать: "Склонируйте bem-express и тд".

i-bem.js Клиентский JavaScript-фреймворк для веб-разработки в рамках БЭМ-методологии.

Почему не TypeScript или хотя бы Flow? Вы же позиционируете фреймворк для больших проектов (с +10 К пользователей в сутки, ага :-)).

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

moment — JavaScript библиотека для синтаксического анализа, валидации и форматирования дат.

На $jin.time не смотрели?

Чтобы закодировать строку методом Base64

btoa("xvz1evFS4wEEPTGEFPHBog:L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg")

Приложение Social Services Search Robot готово.

Возможно я плохо смотрел, но я не заметил там работы с базой данных. Вы делаете запрос к апи сервисов на каждый запрос пользователя? Если так, то такой сервис очень быстро заблокируют по лимитам. Какие уж там "+10 К пользователей в сутки".

[godfreyd]

но я не заметил там работы с базой данных.

Все верно, работы с базой данных нет, так как не стояло такой задачи. Зачем? Задача показать, какие технологии за что отвечают, и какая из них (BEMTREE) ориентирована на работу с данными. Дальше решает сам разработчик.

+10 К пользователей в сутки

Эта фраза относится к тому, что БЭМ обеспечивает надежную и масштабируемую архитектуру, а не к теме поста.

[vintage]

Клиент запускается на машине каждого пользователя. Сервер упирается в масштабируемость nodejs+express. Что такого волшебного может дать БЭМ для "+10 К пользователей в сутки"?

[asavin]

Представим, что в компании Яндекс планируют на следующей неделе начать разработку нового проекта. Какова вероятность, что этот проект будет использовать i-bem и bemhtml, а не тот же React?

[tadatuta]

Ты же знаешь ответ ;)
Зависит от отдела == опыта команды и требований.

[devlev]

Интересно, хоть один человек вдохновился этой статьей и перешел на БЭМ? Мне вот почему то интуиция подсказывает что нет. Да и что это за Hello World, в котором мало того что нужно склонировать начальный проект из репозитория, так еще пару файлов подправить чтобы все заработало. И это на минуточку Hello World! Автор статьи даже не удосужился ее опробывать на windows, ибо на виндоус не выполнится команда rm -rf .git. У меня даже собрать проект не получилось потому что инструкция орентирована только на linux пользователей.

[godfreyd]

Привет. На Windows мы проверяли, все работало и работает сейчас. Попробовал заново все пройти. Все замечательно. Вы GitBash используете?

Результат:

rm -rf .git



Проект SSSR:



Данные по системе

[devlev]

Извеняюсь, теперь и правда все собралось и работает. До этого просто всегда пользовался обычной консолью винды и видимо предупреждение о том что запускать надо только через GitBash осталось в слепой зоне. Спасибо!

[godfreyd]

Да и что это за Hello World, в котором мало того что нужно склонировать начальный проект из репозитория, так еще пару файлов подправить чтобы все заработало.

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

[devlev]

Мне просто показалось логичнее шаблонный репозиторий сразу сделать Hello World. Ну или загрузить его как отдельный подпроект готовой сборкой. Скачал, установил, запустил.

[nitrok]

Спасибо! Расскажите еще, пожалуйста, какие есть варианты это все на прод выкатить? Пусть будет допущение, что у нас простой сайт и мы взяли простой дроплет с nginx и node.js по умлочанию. Что дальше?

[tadatuta]

Дальше все полностью аналогично деплою совершенно типичного сайта на express. В простом случае подойдет какой-нибудь pm2 или аналог, чтобы следить, что процесс жив и добавить его в автозагрузку для переподнятия после рестарта сервера. Плюс мониторинги и прочая безопасность по вкусу.