[Перевод] Сражаясь с БЭМ: 10 основных ошибок и как их избежать13.07.2016 11:48

В некоторых ситуациях, это не возможно. Если, например, ваша сетка не собирается вас слушаться, или вы просто хотите какое-нибудь имя со смыслом для вашего родительского элемента, то что вам делать? Я, как правило, выбираю слово container или list, в зависимости от ситуации. Применяя это к нашему карточному примеру, я бы мог использовать

4. «Кросскомпонентные… Компоненты?»

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

Вкратце, давайте предположим, что мы хотим добавить c-button в наш card__body из предыдущего примера. Эта кнопка уже является его компонентом и оформлена так:

Click me!

Если у вас нет никаких различий между обычным компонентом кнопки, то тогда проблем нет, мы просто переместим ее вот так:

    

        
Title text here
    

    


        
        
Lorem ipsum dolor sit amet, consectetur
        
Adipiscing elit. Pellentesque.

        
        Click me!

    

Однако, что происходит, когда присутствуют небольшие различия в стилях — например, мы хотим ее немного уменьшить, закруглить углы, но только тогда, когда она является частью компонента c-card?

Кросскомпонентный класс показался мне наиболее надежным решением:

    

        
Title text here
    

    


        
        
Lorem ipsum dolor sit amet, consectetur
        
Adipiscing elit. Pellentesque.

                Click me!

    

Это то, что известно на сайте БЭМ, как «микс (mix)». Однако, я изменил свое отношение к этому подходу, следуя некоторым замечательным комментариям от Esteban Lussich.

В примере выше, класс c-card__c-button пытается изменить одно или несколько существующих свойств c-button, но зависит от источника вызова (или даже от специфики), для успешного применения. Класс c-card__c-button будет работать только в том случае, если он определен после блока c-button, который может быстро выйти из под контроля, если вы будете строить больше таких кросскомпонентов. (Полагаться на !important, конечно, можно, но я бы не стал!).

Оформление по настоящему модульного UI элемента должно быть полностью независимо от родительского контейнера — оно должно выглядеть одинаково независимо от того, где вы его расположите. Добавление класса из другого компонента для задания стиля, как это делает способ с «миксами», нарушает открытые/закрытые принципы компонентно-ориентированного дизайна — т.е., не должно быть никакой зависимости от другого модуля для эстетики.

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

Click me!

Даже если вы не используете эти дополнительные классы снова, по крайней мере, вы не будете привязаны к родительскому контейнеру или к исходному порядку для применения изменений.

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

5. «Модификатор или новый компонент?»

Одна из самых больших проблем — решить, где компонент заканчивается, и начинается новый. В примере с c-card, вы бы могли создать другой компонент, названный c-panel с очень похожими атрибутами стилей, но с очень заметными различиями.

Но что определяет необходимость использования двух компонентов, c-panel и c-card, или простого модификатора для c-card, который применяет уникальные стили.

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

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

6. «Как управлять состояниями?»

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

У вас два варианта: или использовать хук автономного состояния, или использовать БЭМ-подобное именование модификатора на уровне компонента:

    […]




    […]

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

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

7. «Когда лучше не добавлять новый класс к элементу»

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

Обычно я прикрепляю классы ко всему, что должно быть стилизовано, по разному, в контексте компонента. Я часто оставляю теги p без класса, если компонент не требует, чтобы они выглядели по-особенному в этом контексте.

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

Ввиду глобального характера CSS, присвоение класса ко всему дает нам полный контроль над рендером. Первоначальный дискомфорт стоит преимуществ полностью модульной системы.

8. «Как вкладывать компоненты?»

Допустим. что мы хотим отобразить чек-лист в нашем компоненте c-card. Пример того, как не стоит это делать:

    

        
Title text here
    

    


        
I would like to buy:

        
        

            

                
                Apples
            
            

                
                Pears
            
        

    
    

У нас тут есть несколько проблем. Первая — двухуровневый селектор, о котором мы узнали в первом разделе. Второе — все стили, примененные к c-card__checklist__item, относятся только к этому конкретному случаю, из-за чего их нельзя использовать снова.

Я предпочитаю разбить список на модуль разметки, предметы чек-листа на их собственные компоненты, что позволяет использовать их самостоятельно в другом месте. Это позволяет вернуться нашему префиксу l- к игре:

    

        
Title text here
    

    


        
I would like to buy:

        
        

            


                
                

                    
                    Apples
                

            
            


                

                    
                    Pears
                

            
        
        

    
    

Это спасает вас от необходимости повторять эти стили, а также значит, что мы можем использовать l-list и c-checkbox в других местах нашего приложения. Это требует немного больше разметки, но взамен мы получаем читаемость, инкапсуляцию и возможность повторного использования. Возможно, вы заметили, что это — основные темы!

9. «Не появятся ли у компонентов миллион классов?»

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

Пример из четырех классов, с помощью которых стилизуется кнопка:

Click me!

Я понимаю, что этот синтаксис немного уродлив, но он понятный.

Однако, если от этого у вас начинает болеть голова, вы можете взглянуть на технику Сергея Зароуски. Фактически, мы будем использовать .className [class^="className"], [class*=" className"] в таблице стилей для имитации дополнительной функциональности в CSS. Если этот синтаксис кажется вам знакомым, то это потому, что Icomoon использует похожий способ для управления селекторами иконок.

С этой техникой, ваш вывод может выглядеть примерно так:

Click me!

Я не знаю, намного ли снижение производительности при использовании class^= и class*= больше, чем при использовании индивидуальных классов, но в теории, это классная альтернатива. Для себя мне хватает варианта с несколькими классами, но мне кажется, что этот способ определенно заслуживает упоминания для тех, кто предпочитает альтернативу.

10. «Можем ли мы изменить реакцию типа компонента?»

Эту проблему поставил мне Arie Thulank, и к которой я пытался найти 100% решение.

Примером может быть выпадающее меню, которое превращается в набор вкладок в заданный момент, или закадровая боковая навигация, которая превращается в панель меню.

По сути, у одного компонента могут быть два разных состояния, продиктованных медиа-запросом.

Для этих двух примеров я склоняюсь к тому, чтобы просто сделать компонент c-navigation, так как изменение в заданный момент — это то, что он делает. Но это заставило меня задуматься, что на счет списков изображений, которые превращаются в карусель на больших экранах? Это проблемный случай для меня, и, так как он хорошо документирован и прокомментирован, я думаю, что в идеале стоит создать отдельный одноразовый компонент для этого типа интерфейса, с понятным названием (таким как c-image-list-to-carousel).

Гарри Робертс упоминал об отзывчивых префиксах, одном из способов управлять этим. Его подход предназначен больше для изменений в макете и написания стилей, а не сдвигая все компоненты, но не вижу причин, по которым мы не можем применить эту технику здесь. Таким образом, вы можете назвать классы так:

В дальнейшем это будет жить в ваших медиа-запросах для соответствующих размеров экрана.
Совет: Вам придется отключать @ с помощью обратной косой черты, как тут:

.c-image-list\@small-screen {
    /* стили тут */
}

У меня не было причин для создания таких компонентов, но этот способ выглядит очень дружелюбным по отношению к разработчику. Другому человеку должно быть достаточно просто понять ваши намерения. Но я не пропагандирую такие имена, как small-screen и large-screen — они использованы только для улучшения читаемости.

Заключение

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

Обо всех ошибках (грамматических, лексических и т.д.) пишите в комментарии, буду рад их исправить. Спасибо за внимание

Комментарии (4)

• mdss

  13 июля 2016 в 09:07

  +1

  ↑

  ↓

  Я считаю, что двойное нижнее подчеркивание должно появляться только однажды, в имени селектора.

  
  Это очень важное правило, о чем написано в методологии. Т.е. делать элемент элемента вообще нельзя, а не просто не рекомендуется.

• TwistedAndy

  13 июля 2016 в 10:31

  +1

  ↑

  ↓

  Если для повышения специфичности приходится использовать ! important, то с кодом по определению что-то не так. По-хорошему за такое нужно давать по пальцам. Поддерживать код с кучей ! important крайне сложно.

  По поводу методологии БЭМ как таковой. Да, действительно, она позволяет решать проблемы с модульностью и переносимостью кода на больших и средних проектах.

  В то же время она обладает и недостатками. Самый основной из них — это многочисленные классы с длинными названиями. Хорошо, если у класса сравнительно короткое имя c-card, как в примерах в статье, но если это будет какой-то c-front-page-slider или c-contact-information, то список классов у элементов может банально перестать вмещаться в окне редактора (80–120 символов чаще всего). Работать с таким HTML-кодом крайне проблематично, да и выглядит он не очень красиво.

  • drakmail

    13 июля 2016 в 10:44 (комментарий был изменён)

    0

    ↑

    ↓

    Чем мне нравится SMACSS — если его правильно использовать, то он сохраняет все плюсы BEM, но при этом позволяет обходиться без очень длинных классов

  • kirillbykov2

    13 июля 2016 в 10:55

    –1

    ↑

    ↓

    В 9 пункте описано довольно неплохое решение для этой проблемы, можно использовать class^= и class*= и тогда это:

    
    

    
      
    
        
    Title
      
    

    
    

    можно превратить в это:

    
    

    
      
    
        
    Title
      
    

    
    

    используя вот это:

    
    

    .container, [class^="container--"], [class*=" container--"] {
      border: 1px solid grey;
      padding: 10px;
      font-family: Arial, sans-serif;
    }
    .container--shopping-cart {
      border: 4px solid orange;
      background-color: #eee;
    }