Comments 18
Вот зачем всё это переносить из веба в разработку приложений?
Справедливый и популярный вопрос)
Основная цель добавить над виджетами еще один слой абстракции, в котором мы будем разделять виджеты компоненты и виджеты элементы, потому что не все виджеты могут существовать отдельно от других
Классический компонентный подход, да виджет сам по себе можно считать компонентом. Но на больших проектах особенно с адаптивной версткой, этот подход очень хорошо себя показал.
Почему не используешь build-методы?
Судя по тому, как создатель BEM (Yandex) забил на него (последние существенные коммиты в github.com/bem были сделаны более года назад, а так bem-tools вообще заморожен), подозреваю, что это уже заброшенная методология, которая скорее всего не будет развиваться, и от которой отказываются. Странно, зачем тащить мертвеца куда-то в новое место?
Ну в самой методологии и нечего развивать...
Методология это не про тулзы, а про подход и мышление, про интерфейсы, а интерфейсы что в вебе что на мобилках одни и Flutter с декларативной версткой отлично вписывается в эту историю.
В Яндексе в вакансиях до сих пор пишут:
Наверное hr копируют по привычке. Надо им подсказать что БЭМ уже умер)
Скорее реакт умрет чем БЭМ)
Вне рунета оно кому-то нужно?
Местами в европах БЭМ юзают.
Ну, например, это использует БЭМ -- https://github.com/material-components/material-components-web
Чтобы узнать, что такое БЭМ, мне пришлось выделить аббревиатуру, нажать Контрол+С, потом открыть новую вкладку и в строку поиска вставить скопированный объект, потом нажать Энтэр... Блин, ну неужели нельзя сразу в начале статьи написать одно предложение, которое бы пояснило, что такое этот БЭМ?
Подробнее почитать о методологии можно здесь.
Кстати, первым делом я перешел по этой ссылке, что заняло тоже время, и там нифига не говорится, что такое БЭМ и нужно было полазить по сайту - что не приемлемо...
Простите за доставленные неудобства.
Для вас специально нашел старую, но в рамках БЭМ актуальную статью
"Верстка для самых маленьких. Верстаем страницу по БЭМу"
Как я вижу, БЭМ возникла на том этапе фронтенда, когда стили всех компонентов существовали в одном пространстве, в одном документе. Да и сами компоненты поддерживались за счет усилий разработчиков, то есть за счет неких договоренностей о нейминге.
В современном фронтенде, с использованием фреймворков, которые сразу дают компонентный подход из коробки в сочетании с CSS modules - все компоненты и стили и без особых усилий имеют разные префиксы и не влияют друг на друга.
В Flutter нет проблемы пересечения селекторов или правил CSS, поэтому говорить о БЭМ в целом не имеет смысла.
Но есть смысл подумать о нейминге, чтобы разделять общие классы и классы, которые используются только внутри какой-то страницы.
Это не обязательно делать за счет подчеркиваний и других пробелов.
Подчеркивания и пробелы возникли в БЭМ только потому, что "All CSS syntax is case-insensitive within the ASCII range... ", то есть camelCase был опасен, так как регистр буквы не учитывался.
В Flutter вы можете смело перейти к camelCase, как и в любом другом случае, когда вам не нужно использовать CSS-правила или пути к директориям (Unix хорошо различает разные регистры в директориях, а вот Windows нет - папка camel и CAMEL там одно и то же)
Да все верно, Flutter лишен тех проблем для которых изначально создавался БЭМ
Разделять да нужно, я долго размышлял на эту тему как это разделить, чтобы это было наглядно, и пока что называть Name__element_modificator для меня кажется вполне удачным.
Если есть идеи лучше чем подчеркивания можно обсудить и сравнить
С принципом разделения виджетов на виджеты я согласен, но только с организационной точки зрения. Аргументация про производительность не верна:
константы лишний раз не перерисовываются в отличие от функции
Виджеты-константы перерисовываются так же, как и обычные виджеты. При каждом их использовании создаются такие же узлы и в element tree, и в render tree . Их плюс в том, что они не пересоздаются каждый раз при перестроении дерева виджетов. Чтобы виджет лишний раз не перерисовывался, используют
RepaintBoundary.Функции могут возвращать константный виджет, который не будет пересоздаваться при каждом ее вызове. Достаточно использовать ключевое слово
constперед вызовомconstконструктора. Это стоит делать и вbuildметодах.При замене функции или метода на константный виджет, мы меняем вызов функции или метода на вызов
buildметода константного виджета фреймворком. Результат этого метода может быть возвращать как константный, так и обычный объект => сама по себе замена функции виджетом не повлияет на производительность в лучшую сторону.
блин у меня слов нет)) боже упаси попасть на такой проект, во флатере и так все ачешуенно зачем туда тащить эту херню
при чем тут фанатизм, я просто не вижу какие проблемы или недостатки БЭМ тут исправил, этот блок элемент модификатор был для чего? для веба а почему? да потому что они там не могли сами придти к какому то единому стандарту, у нас вроде нет с этим проблем, переиспользуемость, в флаттере идет в комплекте создали виджет в файл вынесли где надо вызвали, что может быть проще?
взять технологию которая и в вебе то уже давно умерла и притащить в флаттер где оно не надо от слова совсем вот что такое фанатизм
Как применить БЭМ методологию во Flutter проекте