Мало кто на российском рынке умеет в опенсорс хорошо. Главное, что мы не перестаем пытаться выносить полезное не только нам в компании, но и другим людям. Делится опытом, вот что главное, и то, что помогает развиваться. Я искренне надеюсь, что в опенсорс у нас это будет получаться всё лучше и лучше.
Забегая вперед, скажу, что мы используем Proxy, пример который ты взял, был единственным способом раньше, но если следить за релизами, то будет заметно развитие подхода. Спасибо тебе за предложение разных вариантов работы с реестрами. В следующей статье я расскажу как работаем мы и какие из этих методов нам не подошли и почему.
В статье около 5 ссылок на данный репозиторий. Я специально разделил статью на части, потому что практическая часть будет такой же объемной. Читать двойной объем за один раз не так удобно.
Мы постоянно работаем над эффективностью потребления ресурсов устойства. В Яндекс.Браузере например, есть индикатор использования батареи. В данном же случае с Поиском мы загружаем JS-код лениво, когда пользователь уже начал потреблять контент. А «толстый» JS присутствует только там, где есть интерактивные элементы. Как правило, код, который необходим для их работы загружается за каким-либо событием, и практически никогда в лоб.
Можно тупо пробрасывать классы через пропсы, но это несколько громоздкое и ненадёжное решение. Можно использовать темы через контекст. Можно просто создавать разные компоненты с разными темами.
Всё это просто не будет работать, если вы намерены как и мы шарить бандлы компонентов между сервисами. Мы не можем себе позволить 200 раз загружать одно и тоже на разных сервисах. Почему бы не использовать механизмы браузера для ускорения своих сервисов, вместо того чтобы слепо использовать какие-либо решения.
У нас есть противоположный опыт и будем рады им поделится. Не очень понятно какие ресурсы на какую поддержку ты имеешь в виду. Суть методологии как раз в том, что её не надо поддерживать – её надо использовать. Для поддержки есть мы. Обращайтесь напрямую к нам через issue на Github или пишите в Telegram-канал.
К сожалению, мы не предусмотрели проблемы с v2, надеюсь что новая версия решает все ваши трудности. Подробный гайд по использованию нового API мы опубликуем чуть позже. Было бы интересно глянуть на ваше решение для Django.
1. Да, bemhtml.
2. Есть нюансы в сборке. Мы отделили Angular приложение, как в MEAN стеке, там и пишем директивы. Вьюхи собираются из другой директории и складываются с помощью Gulp. i-bem.js не включается в итоговую сборку скриптов, это искусственное ограничение, чтобы избежать конфликтов.
Есть, конечно. Базовые блоки. Копипаста нет, просто блок, который группа, использует в себе как зависимость другой блок. И в случае смены стиля кнопки, к примеру, стиль группы измениться тоже.
А для чего вам bem tools? Если вы хотите собирать тулзами проект, то можете взять ENB он может собирать все что угодно, а тулзы можете юзать для работы с файловой системой.
Не нужно — не делай. Мысль какрас в том чтобы писать таким образом те блоки, которые ходят из проекта в проект. Это есть тот самый haml, b — хелпер всего лишь. Ты можешь писать как привык на haml и вставлять в общий код переносимые блоки, это не новый шаблонизатор ни в коем случае, не думай так. В итоге тебе нужен хелпер генерации классов, тк писать ручками лень, ок. Пиши в хотелки.
Оформи хотелку в issues, пожалуйста, я поразмышляю. Гем так или иначе ждут большие перемены и интеграция с bem-tools, возможно туда получится добавить твою просьбу.
Еще в пользу отсутсвия такого, что гем имеет настраиваемый синтаксис БЭМ нотации. Не все пишут именно так, то есть не все так разделяют элементы и модицикаторы. В Европе принят несколько другой синтаксис. Хорошо бы такие пожелания направлять сразу в issues на GitHub.
Всё это просто не будет работать, если вы намерены как и мы шарить бандлы компонентов между сервисами. Мы не можем себе позволить 200 раз загружать одно и тоже на разных сервисах. Почему бы не использовать механизмы браузера для ускорения своих сервисов, вместо того чтобы слепо использовать какие-либо решения.
2. Есть нюансы в сборке. Мы отделили Angular приложение, как в MEAN стеке, там и пишем директивы. Вьюхи собираются из другой директории и складываются с помощью Gulp. i-bem.js не включается в итоговую сборку скриптов, это искусственное ограничение, чтобы избежать конфликтов.
Ответил на вопрос? Посмотрите еще вот сюда github.com/verybigman/generator-bem
Оформи хотелку в issues, пожалуйста, я поразмышляю. Гем так или иначе ждут большие перемены и интеграция с bem-tools, возможно туда получится добавить твою просьбу.