使用SASS mixin还是创建单独的类更好？

Question

使用SASS mixin还是创建单独的类更好？

12

在我们的项目中，我们使用SASS进行样式开发。此外，我们使用Bootstrap，并包含下一个众所周知的mixin：

@mixin clearfix {
    *zoom: 1;
    &:before,
    &:after {
        display: table;
        content: "";
        // Fixes Opera/contenteditable bug:
        // http://nicolasgallagher.com/micro-clearfix-hack/#comment-36952
        line-height: 0;
    }
    &:after {
        clear: both;
    }
}

我们在样式中使用它：

.class-example {
   @include clearfix();
   . . .
}

在编译成CSS后，SASS将mixin的所有内容复制到我们使用mixin的每个类中。因此，这是大量重复的代码。我们使用mixin约100次，因此css文件中会增加约1000行额外的代码。

因此问题是：从性能/支持/可读性等方面考虑，哪种方式更好？

使用mixin并允许存在重复代码
创建class .clearfix 并在标记中使用它，如 <span class="example-class clearfix"> ... </span> 以避免重复

如果有更好的解决方案 - 我很乐意听取。欢迎任何评论/讨论。

- Dmitry Volokh

2

如果您使用的是至少3版本的SASS，而不是使用@include，您可以使用%创建一个@extend-only selector，然后在任何地方都可以使用@extend。这样做不会重复代码，而是会自动将.class-example-1、.class-example-2以及其他扩展它的类添加到您的%选择器的选择器列表中。http://sass-lang.com/documentation/file.SASS_REFERENCE.html#extend - jsea

claerfix只是在StackOverflow上的一个打字错误，还是也存在于现实生活中？ - yunzen

哦，抱歉，那只是个打错字。我会纠正的。 - Dmitry Volokh

6个回答

3

像其他人已经说过的一样，对于这样一个简单的实用程序混合类，我会将其定义为扩展，如下所示：

%clearfix {
    //clearfix code
}

然后在SASS中像这样使用它：

.container{
    @extend %clearfix;
}

无论您扩展多少次，它输出的代码都只在CSS中出现一次，而不是出现数百次。我反对在标记中使用类似clearfloat或clearfix的类，除非您真的需要这样做--为什么要弄乱标记，当您可以使用CSS更好、更快地完成它呢？通过在SASS文件中的一个地方轻松更改它，而不是跟踪许多不同的标记文件，这使您可以将所有内容放在一个地方，而不是分散在许多地方，从我的经验来看，这使维护变得更加容易。

- jhned

3

我建议将它制作为 "helper" 类，正如您所说的那样，它们更加灵活，可以放在需要的地方。此外，根据情况不同，有不同的 clearfixes，有些是溢出修复，有些是表格布局修复等等。我宁愿创建一个类，并在需要的地方添加它们，这也使得您的布局类独立于清除修复。因此，它们可以作为独立且可重复使用的代码存在，而无需担心clearfix可能会破坏潜在的布局:)

我将它们用作类来更好和更灵活地进行布局。

编辑，所以我认为您的解决方案2也是最好的，因为它不像您所说的复制100行代码。

- Nopzen

1

我正在使用Bootstrap的less文件进行当前项目的开发，其中mixins.less文件包含以下内容：

// UTILITY MIXINS
// --------------------------------------------------

// Clearfix
// --------
.clearfix {
  *zoom: 1;
  &:before,
  &:after {
    display: table;
    content: "";
    // Fixes Opera/contenteditable bug:
    // http://nicolasgallagher.com/micro-clearfix-hack/#comment-36952
    line-height: 0;
  }
  &:after {
    clear: both;
  }
}

我们可以定义所谓的“mixin”，它们与编程语言中的函数有些相似之处。它们用于将CSS指令分组到方便、可重用的类中。Mixin允许您通过将类名作为其属性之一简单地包含类的所有属性到另一个类中。这就像变量，但是针对整个类。任何CSS类或id规则集都可以以这种方式混合：

.container{
.clearfix();
}

就 clearfix 而言，我只是使用它作为清除浮动的工具，因为这是它所做的唯一任务，Bootstrap提供了一个类来完成这个特定的任务。它独立于其他类。你可以在HTML中这样使用它：

<div class="clearfix"></div>

- Siddharth Pandey

1

我建议使用 mixin，不必担心性能的微小损失。将来，如果您不再希望在某些内容类型上使用 clearfix，则必须浏览所有 html 以删除标记。

保持标记干净并在 css 中进行布局和样式设计总是更安全的。在这种情况下，为了节省未来支持成本，您正在承受非常小的性能损失。如果您认为性能是一个问题，您可能需要考虑设置标记或 css 的方式，以便您不会有太多调用 .clearfix 的类。

- wentz

-1

首先！

我建议不要使用overflow: hidden。这是一种hack，会导致未来的人们混淆代码，特别是对于任何应用此代码的新人。此外，JavaScript开发人员还必须处理与任何位置相关元素的后果。

那么，在所有地方应用clearfix类或仅在SASS中应用include有哪些优缺点呢？

clearfix类

在DOM元素上使用clearfix可以向任何人显示内容正在浮动，而无需进一步查看。clearfix样式只需编写一次，使您的样式表文件更小。

@include clearfix

太好了，让我们在各个地方都使用include并扩展我们的样式表吧。但等等！我确实找到了一个真正使用它的有趣机会，我将出于这个原因使用它。

如果您有不在模板中需要clearfix的类，那么就在整个DOM中编写。我可以想象想要使用包含选项。虽然这相当罕见。

此外，如果页面上正在进行响应式更改的类需要一个clearfix，您可以将其嵌套在一个漂亮的@import media()中，例如bourbon neat。但即使这种情况很少见，因为您可以从一开始就应用clearfix并完成它。

结论

我认为需要达到一个平衡点，这应该是编写SASS时始终如此的情况。但这是我的个人意见 :-P

- Pocketninja

这只是纯粹的观点，原帖作者正在寻找关于性能方面的事实。 - cimmanon

我相信有一个更长的列表？性能/支持/可读性等。 - Pocketninja

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Nils Kaspersson · Accepted Answer

首先，我想提到的是，将overflow: hidden应用于具有浮动子元素的元素会清除浮动，就像包含您所说的clearfix mixin一样。从可读性和性能方面考虑，这可能是最好的选择。我没有任何数据支持overflow: hidden比clearfix实际上更快地呈现，但如果它确实更快，我不会感到惊讶。它的CSS要少得多，因此在下载数据方面肯定是赢家。

然而，并不总是可以使用overflow: hidden，因为您的布局可能涉及一些相对定位。在这些情况下，最佳的表现方法是为.clearfix创建全局类，并将其应用于所有应清除其子元素的元素。虽然听起来似乎不容易维护，但我认为它比在整个CSS中包含该mixin更容易维护，因为您不必在每次更改时清除缓存的CSS。

我的建议是同时使用overflow: hidden和.clearfix。放弃@include clearfix。

理由在于你不能总是只使用一种方法 (有时你可能想要使用 :after 元素进行其他操作，有时你可能希望内容超出其容器)，因此拥有两种方法总是有意义的。

有了这两种方法，您可以适应任何情况。只需记住，您可以将 overflow: hidden 绑定到类名称上，以使其与 .clearfix 一样DRY。

我的看法。

编辑：

或者，但可能不是最理想的，您可以使用@extend创建以下输出：

.element-1,
.element-2,
.element-3,
.element-4,
.element-5 {
  // clearfix stuff
}

这样一来，clearfix 只需要在一个地方定义，而不是在整个文档中多次定义。个人而言，我并不是特别喜欢它，但也许对你来说是有意义的。