原文鏈接：https://css-tricks.com/the-many-ways-to-include-css-in-javascript-applications/，作者：Dominic Magnifico

如有翻譯不準確，請多指正。

歡迎來到這個在前端開發領域極具爭議性的話題！我相信讀到這篇文章的大多數人都曾遇到過關于#如何在JavaScript應用程序中處理CSS#相關的熱門問題。

在這篇文章之前，我想聲明一句：沒有什么硬性標準可以確定在React、Vue或Angular應用程序中處理CSS的哪一種方法是最好的。每個項目都是不同的，每個方法都有自己的優點！這樣說好像有點含糊不清，但我知道的是，我們所處的開發社區中有很多人去不斷尋求新信息，他們希望以更加有意義的方式推動web向前發展。

暫且把關于這個主題先入為主的概念放在一邊，讓我們來看看迷人的CSS體系結構世界吧!

首先讓我們一起來盤點一下這些方法

簡單地搜索“如何將CSS添加到[在此處插入框架]”就能出現一系列關于如何將樣式應用于項目的意見。為了幫助大家進行篩選摘除，我們將從各更高級的角度研究一些常用的方法及其目的。

選項1：傳統樣式表

我們完全可以用一種熟悉的方式開始：一個傳統樣式表，完全可以在應用程序之中鏈接一個外部樣式表，這樣就可以完工了。

我們可以按照我們的習慣編寫CSS，然后繼續我們的生活。這根本沒有什么問題，但是隨著應用程序越來越大、越來越復雜，維護單個樣式表就越來越難了。解析數千行CSS(這些CSS負責設計整個應用程序的樣式)對于從事該項目的任何開發人員來說都是一件痛苦的事情。

樣式級聯看起來很美好但它也變得很難管理，因為你或項目上的其他開發者編寫的一些樣式會在應用程序的其他部分引入回歸。我們之前也遇到過這些問題，并且引入了Sass之類的東西(以及最近的PostCSS)來幫助我們處理這些問題。

我們可以繼續沿著這條路走下去，利用PostCSS的強大功能來編寫非常模塊化的CSS部分，這些部分通過@import規則串在一起。這需要在webpack配置中進行一些工作才能正確設置，但這些事情大家肯定可以處理!

無論你決定用哪種編譯器，你都可以通過標題中的標記獲得一個包含應用程序所有樣式的CSS文件。根據應用程序的復雜程度，這個文件可能會變得非常臃腫，難以異步加載，并且應用程序的其余部分會出現租用者阻塞。(當然，阻塞并不總是一件壞事，但是為了所有的意圖和目的，我們將在這里泛化一點，盡可能避免渲染阻塞腳本和樣式。)

這并不是說這種方法毫無優點，對于小型應用程序，或者由不太關注前端的團隊構建的應用程序，單個樣式表可能是一個不錯的選擇。它在業務邏輯和應用程序風格之間提供了清晰的分離，而且由于它不是由我們的應用程序生成的，因此完全在我們的控制范圍內，以確保我們編寫的內容與輸出的內容完全一致。此外，瀏覽器緩存單個CSS文件相當容易，因此返回的用戶在下次訪問時不必重新下載整個文件。

但是假設我們正在尋找一個更健壯的CSS架構，它允許我們利用工具的強大功能。它可以幫助我們管理一個需要更多微妙方法的應用程序，輸入CSS模塊。

選項2:CSS模塊

單個樣式表中的一個相當大的問題是回歸的風險。編寫使用相當非特定選擇器的CSS可能最終會改變應用程序中完全不同區域的另一個組件。這就是所謂的“作用域樣式”派上用場的地方。

帶作用域的樣式允許我們以程序化的方式生成特定于組件的類名。因此，將這些樣式限定到該特定組件，以確保其類名是唯一的。這將導致自動生成的類名，例如header__2lexd。最后一點是一個哈希值，它是唯一的，因此即使你有另一個名為header的組件，也可以對其應用標題類，并且我們的作用域樣式將生成一個新的哈希后綴，如下所示：header__15qy_。

CSS模塊提供了控制生成的類名的方法(具體取決于實現)，但是我將把這個問題留給CSS模塊文檔來討論。

所有這些都完成之后，我們仍然在生成一個CSS文件，該文件通過標頭中的標記傳遞給瀏覽器。這帶來了同樣的潛在缺點(渲染阻塞、文件大小膨脹等)，當然也有好處主要是緩存作用。但是，由于這種方法的作用域樣式附帶了另一個警告:刪除全局作用域——至少在最初是這樣。

假設你想使用.screen-reader-text全局類，該類可以應用于應用程序中的任何組件。如果使用CSS模塊，則必須使用：global偽選擇器，該選擇器將其中的CSS明確定義為可被應用程序中其他組件全局訪問的對象。只要將包含global聲明塊的樣式表導入到組件的樣式表中，就可以使用該全局選擇器。這不是一個很大的缺點，但是需要逐漸適應。

這是一個：global偽選擇器的示例：

你可能會冒著將一堆用于字體，表格以及大多數站點的通用元素的全局選擇器放到一個單獨的global選擇器中的風險。幸運的是，通過諸如PostCSSNested或Sass之類的魔術，你可以將部分代碼直接導入選擇器中，以使事情更簡潔：

這樣，你可以不使用：global選擇器來編寫局部文件，而直接將其直接導入到主樣式表中。

需要習慣的另一點是如何在DOM節點中引用類名。我將在這里以Vue，React和Angular的各個文檔為例。我還將為你提供一些示例，說明這些類引用在React組件中的使用方式：

同樣，CSSModules方法具有一些很好的用例。對于希望利用范圍樣式，同時保持靜態但已編譯樣式表的性能優勢的應用程序，CSS模塊可能是最適合你的選擇！

在這里也要注意，CSS模塊可以與你喜歡的CSS預處理功能結合使用。Sass，Less，PostCSS等都可以使用CSS模塊集成到構建過程中。

但是，假設你的應用程序可以通過包含在JavaScript中而受益。也許獲得對組件各種狀態的訪問權并根據不斷變化的狀態做出反應也將是有益的。如果你也想輕松地將關鍵CSS集成到的應用程序中去，那就輸入CSS-in-JS吧。

選項3:CSS-in-JS

CSS-in-JS是一個相當廣泛的主題。有幾個包可以使CSS-in-JS的編寫變得盡可能輕松。像JSS、Emotion和樣式組件之類的框架只是構成本主題的眾多包中的一小部分。

作為大多數這些框架的粗略解釋，CSS-in-JS基本上以相同的方式運行。你編寫與單個組件關聯的CSS，并且構建過程將編譯該應用程序。發生這種情況時，大多數CSS-in-JS框架只會輸出在任何給定時間在頁面上呈現的組件的關聯CSS。CSS-in-JS框架通過在應用程序的

中的

我們還需要解決CSS-in-JS解決方案的潛在缺點——而且絕對不要試圖引發更多的鬧劇。使用這樣的方法，我們很容易陷入一個陷阱，這會導致我們得到一個膨脹的JavaScript文件，其中可能包含數百行CSS——而這一切甚至在開發人員看到任何組件的方法或其HTML結構之前就已經出現了。

然而，我們可以將此視為一個機會，來非常仔細地檢查我們是如何以及為什么以這種方式構建組件的。通過更深入地考慮這一點，我們可以潛在地利用它，并使用更多可重用組件編寫更簡潔的代碼。

此外，此方法絕對模糊了業務邏輯和應用程序樣式之間的界限。但是，有了一個有據可查且經過深思熟慮的體系結構，該項目中的其他開發人員可以輕松地采用這種想法，而不會感到不知所措。

寫在最后

有多種方法可以處理任何項目上的CSS體系結構的難題，并且可以在使用任何框架時進行處理。作為開發人員，我們擁有如此眾多的選擇，這既令人興奮，又令人難以置信。但是，我認為，最終我們會在超短的社交媒體對話中迷失的首要原因是——每種解決方案都有其優點和效率低下的弊病。這是關于我們如何謹慎，周到地實施使我們自己/或其他可能接觸代碼的開發人員的系統的感謝，感謝我們花時間建立該結構。

總結

以上是生活随笔為你收集整理的css如何调整红心样式_在JavaScript应用程序中包含CSS的多种方法「渡一」的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。