我们如何使用模块来组织我们的前端代码_极简慕枫

苏州网站建设

有没有想过像Tuts +这样的大型网站如何通过持续的开发和迭代来保持其CSS，HTML和JavaScript的顺序？我将向您展示我们实施的过程，以保持整洁和可维护。

CSS的问题

这个过程的第一步是找到一种方法来构建我们需要的大量CSS，这些CSS不会不可避免地以混乱结束。

传统上使用CSS，您可以根据需要构建样式，并努力使您的选择器广泛适用，以便它们可以在整个站点中重用。例如，这里有一些简单的CSS规则，在大多数样式表中都不会感觉不合适：

如果需要在页面的特定部分中覆盖这些选择器，则可以使用嵌套规则来构造以更具体元素为目标的选择器：

这种方法在直觉上是正确的，但是一旦到达具有多个页面的站点并且多个开发人员正在处理的站点，它可能会遇到一些重大问题。

当我们改变整体风格h1或.subtitle在全球范围内时会发生什么？font-size已经被更具体的风格所覆盖，但如果我们添加一个font-weight或line-height它不会。如果没有对网站上所有样式的深入了解，对全局样式所做的任何更改都会以不可预测的方式产生影响并影响更具体的样式。

以这种方式构建的样式越多，相互作用的CSS样式的“副作用”就越明显，需要进行无聊的试验和错误，最终导致生产力的损失和越来越多的错误蔓延到生产中。

BEM模块

为了帮助防止出现此问题，我们采用了基于BEM方法的 CSS 方法。不是定义全局应用的样式，而是通过命名约定将所有样式分解为自包含的“块”。“块”或多或少地被定义为可以重复使用的单个独立的内容单元（尽管实际上不重复使用它并不是强制性的）。

例如，让我们看一下“精选部分”块：

根据我们的命名约定，此块具有div带有类名的根元素featured-sections。它包含具有类名称的元素，例如featured-sections__title和featured-sections__section-link。

我们正在为源代码使用匹配的命名约定，因此此featured-section块的所有样式都存储在modules/featured_section.sass：

此命名约定可确保样式不再冲突和混合。只要遵循我们的命名约定，在每个类名的开头使用块名称，样式就不可能影响其自身块之外的某些东西。

它还可以非常容易地找出在代码库中查找与元素相对应的样式的位置。您只需查看元素的类名，您就会知道要打开的样式表的名称。

模块化视图代码

我们选择进一步将此命名约定应用于我们的视图。每个块都有一个视图部分具有相同的名称，存储在views/modules。例如，我们featured-sections块的HTML视图存在于views/modules/_featured_sections.html.slim：

与使用CSS文件的命名约定使得查找CSS样式变得容易的方式相同，对视图使用这种命名约定可以轻松查找视图代码。当您在浏览器中查看页面并注意到需要进行某些更改的特定部分时，这会派上用场。您可以只执行“检查元素”并使用在元素的CSS类中清晰可见的块名称来帮助您直接跳转到相关的视图文件。

模块化JavaScript

我们还继续为我们的JavaScript代码采用了相同的命名约定，并得到了Backbone.js的一些帮助。

需要应用JavaScript行为的每个块都使用相同的块名称获取Backbone视图对象：

我们编写了一些视图加载代码，这些代码在页面加载时应用，因此为每个元素自动加载适当的Backbone视图，其中CSS类与具有关联JS的块名称列表相匹配。

我们对JavaScript代码使用相同的文件命名约定，从而产生如下所示的全功能块的结构：

一般适用性

我强烈推荐这种方法用于任何项目。我认为在开展大型项目时这是非常宝贵的，即使你在一个小得多的网站上工作，以模块化方式构建前端代码也没有什么缺点。

也就是说，如果您已经拥有大量的全局CSS样式，或者如果您依赖于Twitter Bootstrap等CSS库，则可能会遇到尝试使用此策略的问题。由于BEM样式使用单个类名作为其选择器，因此它们具有非常低的CSS“特异性”值，并且往往被全局CSS样式践踏，这些样式通常具有多级嵌套选择器，以及标记名称和ID。

绝对有可能从全球CSS风格转变为更模块化的BEM风格，从长远来看，我认为非常值得。但是，确实有一段时间构建BEM样式会稍微困难一些，并准备好在!important整个CSS中添加至少一些临时声明，直到您能够完全摆脱全局样式。

 苏州网站建设