Comments 35
А что скажете насчёт этих идей в применении к вашим реалиям?
MAM: сборка фронтенда без боли
А что стало с уровнями переопределения при "явном лучшем неявного"?
То есть, если надо перекрасить кнопочку в глубине какого-то компонента, то придётся переопределить все компоненты по пути к этой кнопочке на кастомные?
Подробнее о том, как работает bem-react/di можно посмотреть в докладе verybigman www.youtube.com/watch?v=nhgC_43C38Q
Вот это вот "если догадался" и смущает. Откуда разработчику знать какая кастомизация потребуется? А если он будет заводить слоты для всего на свете, то боюсь кода будет слишком много и разобраться в нём будет ни чуть не проще, чем изучить правила "магии".
К моему личному сожалению, безграничная гибкость БЭМ-стека новым разработчикам «заходит» хуже, чем явные импорты, пусть даже и требующие рефакторить компоненты каждый раз, когда становится понятно, что вовремя забыли позаботиться о кастомизации на будущее.
В документации репозитория описано и как подключиться к обсуждению/разработке и мотивация, почему все сделано именно так, как оно сделано: github.com/bem/bem-react/blob/master/docs/ru/Introduction/Motivation.md
Всегда рады конструктивной критике и предложениям!
К сожалению, там нет обоснования необходимости Реакта. На мой взгляд это тупиковая ветвь развития. Его использование откатывает индустрию в каменный век и требует снова решать уже давно решённые проблемы. Мне кажется Яндекс вполне в состоянии не прогибаться под чужой маркетинг, а сам задавать тренды.
Мы верим, что именно сообщество со временем позволит Реакту получить все лучшее из других миров, как это когда-то произошло с jQuery. А потом, как и jQuery, Реакт выйдет на пенсию. Но еще до этого все забудут несколько сотен опередивших свое время фреймворков ;)
заняться поддержкой и продвижением $mol хотя бы том же уровне на котором вы поддерживаете bem-react
Поддержкой bem-react мы занимаемся не только из любви к искусству, но и потому что сами его используем в собственных проектах в продакшене. Будет странно, если мы начнем активно развивать технологию, опыта с которой у нас нет. Но мы готовы помочь сообществу $mol консультациями по части интеграции с БЭМ, если таковые потребуются.
А $mol почему не используете? Особенно в свете того, что в нём реализованы и получили дальнейшее развитие идеи БЭМ.
на явное — ниже порог входа
Это актуально, если менять штат каждые пол года. Мне казалось это не ваш случай, и вы рассчитываете, что разработчики будут работать у вас как минимум несколько лет. В этом случае важнее максимальная скорость, а не ускорение. Мне очень не хочется верить, что в Яндексе настолько большая текучка, что приходится подстраивать технологии под человека с улицы, а не человека с улицы подтягивать по технологиям.
И это даже если не говорить о том, что в МАМ самый минимум соглашений, который можно освоить быстрее, чем пройти собеседование в вашу компанию.
мы повсеместно переходим на 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. На сообщество, к сожалению, нельзя полагаться. Особенно в долгосрочной перспективе. Поэтому, выбирая фреймворк, стоит быть готовым к тому, что в какой-то момент придётся встать перед выбором: либо брать его под своё крыло и развивать дальше самим, либо переписывать весь код на другой фреймворк. Впрочем, если вы не мелкая контора из глубинки, то вполне в состоянии выделить одного человека, для создания и развития фреймворка в том направлении, что нужно вам, и не полагаться на тенденциозное сообщество вообще.
При желании можно сравнивать количество коммитов в день, количество коммитов от менее активных контрибьюторов или наоборот гордиться, что коммитов так мало, потому что ядро более-мене стабилизировалось (или в основном идет во внутренней системе контроля версий определенной корпорации ;)
Еще можно считать количество сопутствующего кода, статей, обучающих видео и так далее.
Статистика благодушно позволит защитить совершенно любую точку зрения )
Но вот с аргументом про Ангуляр действительно невозможно спорить.
Спасибо за sneak peek в ваши процессы разработки!
tadatuta а можете рассказать поподробнее про взаимоотношение реализаций на i-bem и React? Это две отдельные кодовые базы или есть какое-то переиспользование?
А на файловой системе это как организуется? Файлы лежат рядом, что-то вроде такого:
desktop.blocks/
button/
button.common.js
button.i-bem.js
button.react.jsxили как-то иначе?
desktop.blocks/**
Вы сначала пишете про 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-ы в проекты обновятся на использование этой стабильной версии. Так что разработчикам останется только их влить.
Общие компоненты силами разных команд. Доклад Яндекса