關於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本身來處理特定情況的特質。只是想一想...