Question

我正在开发一个包含一些复杂mixin的项目。我们正在使用修改后的BEM类命名策略，因此典型的mixin看起来像这样：

@mixin mixin__nestedHeader {
    color: grey;

    &__title {
        font-size: 1.2em;
    }

    &__message {
        font-size: 0.6em;
    }

}

这将设置一个看起来像这样的HTML块：

<div class="header">
    <h4 class="header__title">Title Text</h4>
    <div class="header__message">Message Text</div>
</div>

因此，我们遇到的问题是mixin决定了我们的HTML结构。一方面，我们希望这个HTML总是风格相同，因为我们使用mixin，所以需要它始终是相同的不是世界末日。但是，如果此HTML代码已经嵌套在＆＃34;项目中，那么＃34;阻止，它导致我们的类成为＆＃34; item__headerTitle＆＃34;和＆＃34; item__headerMessage＆＃34;这使混合不起作用。

现在，我们可以在mixin上使用参数添加类，这就是罗盘所做的。但是，这使混合使用起来更加复杂。

我想知道每个人对于让mixin决定使用什么HTML结构的想法。你是否只是处理它，因为你得到了使用mixin的好处？或者这对你来说是一个破坏性的东西，它会让你远离那些使用特定类命名来设置多个元素的复杂混合。没有错误的答案，我们只是试着看看人们的想法。

Answer 1

TL; DR：通过无偿的代码评论，我认为在造型中规定结构是好的。另外，让你的mixin接受参数使其使用起来更灵活，但构建/维护的指数更复杂。如果你对这种权衡感到满意，那真的很难想。

在任何种类的环境/语言中工作，最好在它开始生产之前进行编译或缩小，这是一件好事，它可以让你对代码注释非常冗长。充其量，它们可以成为一个非常有用的见解，了解东西的工作原理。在最坏的情况下，它们很容易被忽略，并且在编译生产时会被剥离，所以确实没有成本。 SASS也不例外。

记住这一序言......
我在过去做过类似的事情，我们使用placeholder selectors作为特定元素族的基本样式，根据情况，每个元素都会以自己独特的样式进行扩展。这些元素需要使用的标记结构，以及如何编写和扩展样式都包含在特定的SASS中。它最终看起来像：

%full-width-story-block {
/* Can be included with article.story-block elements which need to occupy their container's full width.
   See "Usage" section after the style definitions for notes & examples. */

  flex-basis: 100%;
  display: flex;

  & > * {
    @include make-col(6);
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-content: center;
  }
  & > div {
    padding-left: $story-block-spacing*2;
  }
  & > a { display: block; }
  @include media-breakpoint-up(md) {
    h3 { padding-top: 0; }
  }

  @include media-breakpoint-down(sm) {
    flex-wrap: wrap;

    & > div {padding-left:0;}
    & > * {
      @include make-col(12);
    }
  }

/*  Usage :
    + Ensure that the element is rendered on the page in the following pattern:
      (note the div containing everything but the 1st anchor/image tags.
       This is generally not included when story-block elements are used in "Content Walls")

        <article id="post-4321" class="story-block">
            <a href="/link/to/post"> <img src="story-pic.jpg" /> </a>
            <div>
              <h3> <a href="/link/to/post">Story Title</a> </h3>
              <p>A short excerpt from the article...</p>
              <div class="save-article">
                <a class="save-to-pocket" href="/pocket/url"/> <svg>...</svg></a>
                <a class="save-to-instapaper" href="/instapaper/url"/> <svg>...</svg></a>
              </div>
            </div>
        </article>

    + Extend the styling to the element container:
          .container-needing-full-width-story-block {
              .story-block { @extend %full-width-story-block; }
          }
*/
}

最重要的是沟通信息在那里并在实施中保持一致。有几个不同的组件系列共享这种结构，并且每个组件都以类似的方式在代码注释中列出了所需的标记结构和扩展过程。这使得其他开发人员很容易出现并开始使用＆amp;扩展我们已经花费时间设置的结构。

此外，所有这些文档（缺少一个更好的词）都存在于代码库本身中，这意味着默认情况下所有这些知识都会被项目文件移植。因此，在需要应用修复或更新的2年内，只要我们拥有代码库，我们就不会尝试追踪一些不起眼的内部知识库/维基文章或最初构建它的开发人员。

所有这一切，我会提醒你写一些可以接受争论的东西。从理论上讲，它确实允许标记结构具有更大的灵活性，但这种灵活性的代价是增加了构建和维护混合的复杂性。我已经看到/构建了具有良好意图的东西，但最终变得非常“切换案例”-ey，在项目的其他地方每次使用mixin都需要更改mixin本身来处理特定情况的特性。只是要考虑一下......

关于需要特定HTML结构的mixin的想法？

1 个答案: