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

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代码已经被嵌套在“项目”块中，它使我们班成为“item__headerTitle”和“item__headerMessage”这使得混入不起作用。现在

，我们可以添加使用的混入，这是做什么指南针参数的类。但是，这使得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; } 
      } 
*/ 
} 

重要的是沟通，信息在​​那里，并在实施中一致。有几个不同的组件族共享这种结构，并且每个组件都有类似的标记结构和扩展过程，以类似的方式在代码注释中列出。这使得其他开发者很容易就可以开始使用，扩展我们已经花费时间建立的结构。

而且，这一切文件（对于缺乏一个更好的词）的代码库本身存在的事实意味着所有这方面的知识将与默认情况下，项目文件被移植左右。因此，在2年内，当需要应用，只要我们的代码基修复或更新，我们不会试图追查一些不起眼的内部知识库/ wiki文章或谁最初建造它的开发者。

所有这些说法，我会提醒你写一些会接受论据的东西。从理论上讲，它确实允许标记结构具有更大的灵活性，但这种灵活性的代价是增加构建和维护mixin的复杂性。我已经看到/构建了那些有着良好意图的事物，但最终结束成为“切换案例” - 因此，项目中其他地方每次使用mixin需要更改mixin本身来处理特定情况的特质。只是想一想...