Как стать автором
Обновить

Комментарии 35

Мы достаточно много экспериментировали с «магической» сборкой, которая также, как и в МАМ, не требовала указания явных импортов. В частности такой подход позволил очень удобно работать с уровнями переопределения. Но сейчас скорее движемся в сторону «явное лучше неявного» и возвращаемся к классическим импортам, которые хотя и заставляют писать больше бойлерплейта, зато делают код более очевидным, не требующим знать о соглашениях, чтобы с ним разобраться.

А что стало с уровнями переопределения при "явном лучшем неявного"?

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

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

Подробнее о том, как работает bem-react/di можно посмотреть в докладе verybigman www.youtube.com/watch?v=nhgC_43C38Q

Вот это вот "если догадался" и смущает. Откуда разработчику знать какая кастомизация потребуется? А если он будет заводить слоты для всего на свете, то боюсь кода будет слишком много и разобраться в нём будет ни чуть не проще, чем изучить правила "магии".

НЛО прилетело и опубликовало эту надпись здесь
Ровно по такой логике мы и проектировали компоненты раньше. И до сих пор большая часть кодовой базы по-прежнему реализована на идеях, схожих с MAM.

К моему личному сожалению, безграничная гибкость БЭМ-стека новым разработчикам «заходит» хуже, чем явные импорты, пусть даже и требующие рефакторить компоненты каждый раз, когда становится понятно, что вовремя забыли позаботиться о кастомизации на будущее.
НЛО прилетело и опубликовало эту надпись здесь
Мы ведем разработку и обсуждение максимально открыто на github: github.com/bem/bem-react

В документации репозитория описано и как подключиться к обсуждению/разработке и мотивация, почему все сделано именно так, как оно сделано: github.com/bem/bem-react/blob/master/docs/ru/Introduction/Motivation.md

Всегда рады конструктивной критике и предложениям!

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

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

Мы верим, что именно сообщество со временем позволит Реакту получить все лучшее из других миров, как это когда-то произошло с jQuery. А потом, как и jQuery, Реакт выйдет на пенсию. Но еще до этого все забудут несколько сотен опередивших свое время фреймворков ;)
НЛО прилетело и опубликовало эту надпись здесь
заняться поддержкой и продвижением $mol хотя бы том же уровне на котором вы поддерживаете bem-react


Поддержкой bem-react мы занимаемся не только из любви к искусству, но и потому что сами его используем в собственных проектах в продакшене. Будет странно, если мы начнем активно развивать технологию, опыта с которой у нас нет. Но мы готовы помочь сообществу $mol консультациями по части интеграции с БЭМ, если таковые потребуются.

А $mol почему не используете? Особенно в свете того, что в нём реализованы и получили дальнейшее развитие идеи БЭМ.

Как минимум по тем же причинам, по которым мигрируем с собственного стека технологий, базирующегося на соглашениях, на явное — ниже порог входа, гораздо выше поддержка всевозможных инструментов (в частности мы повсеместно переходим на TypeScript), размер сообщества (а значит — шанс, что в ближайшем будущем проблемы будут исправлены, а новые фичи внедрены) и так далее.
на явное — ниже порог входа

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


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


мы повсеместно переходим на TypeScript

Как славно, что $mol изначально написан на TypeScript и не имеет проблем Реакта с его чисто js-экосистемой, с вечно отстающими тайпингами, написанными "сообществом".


размер сообщества (а значит — шанс

А какова величина этого шанса, что сообщество решит какою-либо проблему до вашего дедлайна? Ну вот, например, проблему репарентинга уже 4 года не могут решить. Хотя решается она элементарно.

Это актуально, если менять штат каждые пол года


… или просто стабильно увеличивать штат на заметный процент.

А какова величина этого шанса, что сообщество решит какою-либо проблему до вашего дедлайна?


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

Кроме того, несравнимо выше шанс, что когда один конкретный автор фреймворка устанет им заниматься, комьюнити не даст ему загнуться (нужно понимать, что переезд со стека на стек в масштабах Яндекса — это миграция на несколько лет).
Предположу, что примерно на 2 порядка выше, чем в случае с фреймворком, где на 2 порядка меньше контрибьюторов.

К сожалению, всё немного сложнее..


https://github.com/facebook/react/graphs/contributors — 7 активных контрибьюторов


https://github.com/vuejs/vue/graphs/contributors — 1 активный контрибьютор


https://github.com/eigenmethod/mol/graphs/contributors — 2 активных контрибьютора


Ситуация по скорости решения проблем:


когда один конкретный автор фреймворка устанет им заниматься, комьюнити не даст ему загнуться

Как-то это огромное комьюнити не сильно-то и помогло AngularJS. На сообщество, к сожалению, нельзя полагаться. Особенно в долгосрочной перспективе. Поэтому, выбирая фреймворк, стоит быть готовым к тому, что в какой-то момент придётся встать перед выбором: либо брать его под своё крыло и развивать дальше самим, либо переписывать весь код на другой фреймворк. Впрочем, если вы не мелкая контора из глубинки, то вполне в состоянии выделить одного человека, для создания и развития фреймворка в том направлении, что нужно вам, и не полагаться на тенденциозное сообщество вообще.

Как известно, есть ложь, наглая ложь и статистика ;)

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

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

Статистика благодушно позволит защитить совершенно любую точку зрения )

Но вот с аргументом про Ангуляр действительно невозможно спорить.
НЛО прилетело и опубликовало эту надпись здесь
Я не могу отвечать за весь Яндекс. В моей области ответственности проекты с нуля случаются раз в сто лет. Вероятность переписывания существующих проектов, где я принимаю участие, на $mol на текущий момент стремится к нулю.
НЛО прилетело и опубликовало эту надпись здесь
пригласить vintage в здание 1 на ул. Казанской с докладом о $mol в вашей области ответственности?


Да, можем считать этот комментарий приглашением ;)
Детали готов обсудить в почте: tadatuta@yandex-team.ru.
НЛО прилетело и опубликовало эту надпись здесь

Спасибо за sneak peek в ваши процессы разработки!


tadatuta а можете рассказать поподробнее про взаимоотношение реализаций на i-bem и React? Это две отдельные кодовые базы или есть какое-то переиспользование?

Стараемся выделять в CommonJS, то, что можно использовать из i-bem и React + используем общие тесты и стили для компонентов.

А на файловой системе это как организуется? Файлы лежат рядом, что-то вроде такого:


desktop.blocks/
  button/
    button.common.js
    button.i-bem.js
    button.react.jsx

или как-то иначе?

В Лего сейчас именно так. На проектах — по-разному. Для мира i-bem четкая структура важна, а для Реакта с явными импортами код может лежать как решит каждая конкретная команда и зачастую принимают решение все-таки держать код на Реакте отдельно, но импортировать стили/тесты из тех же desktop.blocks/**

Ясно. Спасибо за ответы!

НЛО прилетело и опубликовало эту надпись здесь

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

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

В целом схема в CI такая:
1. Открытие pull request-а в репозиторий с общим кодом автоматически выпускает canary-версию затронутых пакетов
2. Во все проекты, где используется затронутый пакет, автоматически отправляется pull request с обновлением package.json и package-lock.json до версии, выпущенной в п. 1
3. Эти pull request-ы триггерят запуск тестов в затронутых репозитория
4. Отчеты по этим тестам публикуются в исходный pull request из п. 1. Если там упали обязательные проверки, влиться не получится
5. Если все проверки прошли успешно и разработчик вмержил изменения, автоматически будет выпущена стабильная версия общего пакета, а pull request-ы в проекты обновятся на использование этой стабильной версии. Так что разработчикам останется только их влить.
А можете рассказать как это же происходит для мобильных приложений?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий