和BEM的战斗：10个常见问题及如何避免

在一些情景下，布局模块是不可能的完全满足要求的。比如说你的网格没有能给你想要的结果，或者你只是想要去语义化的命名一个父元素，你应该怎么做？在不同的场景我倾向去选择contaniner或者list。还是我们card的例子，我可能会用

我们面临的另一个常见的问题是组件的样式和位置会受到父级容器的影响。就这个问题Simurai有很多详细的解决办法。我这里说一个拓展性最好的方式。

假设我们想要在之前的示例的card__body中加入一个c-button。这个按钮本身已经是一个组件并且结构如下：

`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!

    
 

这就是BEM官网上著名的“mix”。但是，参考了一些从Esteban Lussich的评价之后，我改变了对这种方式的看法。

在上面的例子中，c-card__c-button类尝试去改变一个或多个c-button中存在的属性，但是成功应用这些样式取决于他们的源顺序（或者特殊的指定）。c-card__c-button类只会当它在源代码里声明在c-button类之后才会生效。在你构建更多跨组件的组件时会很快失控。（当然，使用!important也是一种选择，但是我不建议你这样做）

一个真正模块化的UI元素的父元素应该是完全不可知的-无论你在何处使用它，效果都应该是一致的。像“mix”方式那样为另一个组件添加具有特定样式的类名，违反了组件驱动设计的开/关原则，即样式在各模块之间不应该有依赖关系。

最好的办法就是在这些微小的样式差别中使用同一个类，因为你会发现随着项目的增长你会在别的地方对它进行复用。

`Click me!`

即使你不会再使用这些类，为了应用这些修改，至少也不能把他们和父容器、特殊属性和源顺序耦合在一起。

当然，另一个选择就是回到你的设计师岗位，告诉他们这个按钮应该和网站上的其他按钮保持一致，这样就可以完全避免这个问题。但这是另一码事了。

决定组件的起止是一个大问题。在c-card这个示例里，你可能之后会创建另一个叫c-panel的组件，他们两个样式相仿，只有一些细微的差别。

但是是什么决定他们应该是两个组件呢？c-panel和c-card这个块名，或者仅仅是因为一个修饰器在c-card里应用了特殊的样式。

这样很容易过度模块化并且让一切都变成一个组件。我建议从修饰器开始，但是如果你发现你特定组件的CSS文件正变得很难维护，这时候就可以停止使用修饰器。当你发现你为了适应你新的修饰器而不得不去重置这个“块”所有的CSS时，就是需要新组件的好时机-起码对我来说是这样的。

如果你和其它开发者或者设计师协作，最好的方式是去询问他们的意见并且花几分钟去讨论。我知道这样可能有点逃避责任，但是对于一个大型项目来说，理解哪些模块是可复用的并且在组件的构成上达成一致是至关重要的。

这是一个常见的问题，特别是当你给一个活跃状态的组件编写样式的时候。让我们假设cards有一个活跃状态，当我们点击它时，它们会被添加上一个好看的边框。你会怎么去命名这个类？

在我看来你有两种选择：独立的状态钩或者是一个在组件级类似BEM方式命名的修饰器。

    […]




    […]
 

尽管我更倾向于保持一致性的类似BEM的命名方式，独立类名的好处是使用JavaScript来在任意一个组件中应用一般的状态钩更容易。当你不得不使用脚本去应用特定的基于修饰器的状态类时，类BEM的方式就很让人头疼了。这当然是完全可行的，但是意味着你需要为每种可能性去编写更多的JavaScript代码。

坚持使用一系列标准的状态钩是有意义的。Chris Pearece有一个编译好的列表，我推荐你去了解一下。

我可以理解很多人在需要构建一个复杂UI的时候面临的痛苦，特别是他们不习惯去在每个标签上添加一个类。

通常，我会在需要特殊样式的部分上下文添加类名。我会把p标签级的舍弃，除非在这个组件中有特殊的需求。

可以预见，这意味着你的html中会包括非常多类名。最终，你的组件可以独立运行并且在没有副作用的条件下在任何地方使用。

由于CSS的全局特性，在所有部分都添加类让我们可以完全控制我们组件的渲染。最初的心理不适在一整个模块化的系统完成后是完全值得的。

假设我们想要在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。可能这意味着更多的标记，但是对于可读性，封装性和可复用性来说代价可以忽略。你可能已经注意到这些是共同的主题！

有些人认为每个元素有大量类名是不好的，--modifiers会越积越多。就我个人而言，我不认为这是个问题，因为这意味着代码更具有可读性，我也能更清楚的知道它是用来实现什么的。

举个例子，这是一个具有四个类的按钮：

`Click me!` 

我第一眼看到的时候觉得语法不是最简洁的，但是非常清晰。

如果这让你非常头痛，你可以查看Sergey Zarouski提出的拓展技术，我们可以在样式表中使用.className [class^="className"]和[class*=" className"]来效仿vanilla CSS的拓展功能。如果语法看起来很眼熟，可能是因为和Icomoon处理它的icon选择器的方式非常类似。

使用这种技术，你的代码可能会看起来像下面这样：

`Click me!` 

我不知道使用class^=和class*=选择器是否比独立的类名表现更好，但是理论上来说这是一个不错的选择。我喜欢使用复合类名，但我觉得这值得那些倾向于寻找替代品的人注意一下。

这是Arie Thulank给我提出的问题，我花费了很多心思去想出一个100%具体具体的解决办法。

一个例子就是下拉菜单在给定断点处转换为选项卡或者是隐式导航在给定断点处转换为菜单栏。本质上是一个组件在媒体查询的控制下有两种不同的样式表现。

我倾向于给这两个例子去构建一个c-navigation组件，因为他们在两个断点处的行为本质是相同的。但这让我陷入沉思，如果是图片列表在大屏幕上转化为轮播图呢？这对我来说是一个边缘情况，只要它有可行的文档及评论，我认为这是合理的。可是使用明确的命名（像c-image-list-to-carousel）来为这种类型的UI构造一次性的独立组件。

Harry Roberts写过一篇响应式后缀来解决这个问题。他的做法是为了适应更多布局和样式的变化，而不是整个组件的变化。但我不明白为什么这项技术不能被应用在这里。所以，你会发现作者写的样式像下面这样：

`
` 

对于不同的屏幕尺寸，这些类就会保留各自的媒体查询。提示：在CSS中你需要在@前加上来进行转义，像下面这样：

.c-image-list@small-screen {
    /* styles here */
} 

我没有太多构造这种组件的示例，但是如果你需要构造这种组件，这将是一个对开发者非常友好的方式。下一个加入的人应该可以轻松理解你的想法。我不提倡你使用像small-screen和large-screen这样的命名，他们只是单纯为了可读性。

BEM在我创建一个模块化和组件驱动的应用时帮了大忙。我已经使用它大概有三年了，上面的这些问题是我在探索时遇到的阻碍。我希望你认为这篇文章是有用的。如果你还没有想要体验BEM，我非常鼓励你去尝试一下。

本文根据@David Berner的《Battling BEM (Extended Edition): 10 Common Problems And How To Avoid Them》所译，整个译文带有我自己的理解与思想，如果译得不好或有不对之处还请多多指点。如需转载此译文，需注明英文出处:https://www.smashingmagazine....