記錄--記一次前端CSS升級

這里給大家分享我在網上總結出來的一些知識，希望對大家有所幫助

目前平臺前端使用的是原生CSS+BEM命名，在多人協作的模式下，容易出現樣式沖突，為了減少這一類的問題，提升研效，我調研了業界上主流的7種CSS解決方案，并將最終升級方案落地到了工程中，

樣式沖突的原因

目前遇到的樣式沖突的原因，其實根本原因還是css樣式混亂使用導致的：

1. 多人協作，樣式互相污染，這是專案中的主要問題，用開發規范來限定、用CR流程來保障，并不可靠
2. 參考大量第三方組件庫，組件庫對CSS的使用不規范，比如bee.css中使用了大量！important，破壞了專案中的樣式優先級；rsuit是前端非常強大的表格組件庫，他的css檔案中也有直接覆寫底層樣式的寫法label{ marign:2px }
3. 直接使用組件庫引入的css檔案，比如import material-icons.css，如果參考順序靠后，這些檔案可能會覆寫開發人員手寫的樣式，
4. ...

調研方案

CSS作為前端三劍客之一，幾乎是所有前端同學最先學習的樣式表語言，在生產環境的專案工程中，很少見到直接原生使用CSS的，但目前業界還沒有通用的CSS工程化方案，這篇文章先簡單介紹下7種在React/Next.js中較為流行使用CSS的方式，并說說他們的優缺點，

原生 CSS

這是一種用選擇器來劃分css作用域的方式，

• 缺點：

1. 作用域問題 CSS樣式之間會層疊覆寫，需要用大量的classname來指定選擇器，來限定CSS的作用域范圍，頻繁的命名給開發人員增加不少心智負擔，而且容易搞錯搞重復，

// pure css example
.card {
	/* styles */
}
.card__header {
	/* styles */
}
.card--focus {
	/* styles */
}

采用BEM規則來進行命名或許會簡單些， 但在需要維護特別多樣式的時候，BEM還是不夠用，尤其是當代碼中開始大量出現!important這種破壞優先級的東西的時候，

// css with !important
.card {
	color: blue !important;
}
.card {
	color: red;
}

2. 打包體積大 使用大量冗長的原生CSS，可能會導致 打出來的包變大，包越大，專案自然跑的就越慢，

CSS MODULES

這是一種在原生CSS的基礎上，通過modules（也可以理解為檔案）來劃分CSS的作用域，

首先先建一些以.module.css結尾的檔案，這些檔案里的樣式可以只針對某個組件（某個module）生效，這種做法在Next.js尤為常見，因為CSS modules在Next.js是可以開箱即用的，

下面是一個例子，在Home.module.css和other.module.css對同樣的類名書寫樣式，也不會產生沖突，

@file Home.module.css
.page {
	color: bule;
}

@file other.module.css
.page {
	color: yellow;
}

// 只會生效這里import的樣式
import styles from '../styles/Home.module.css';
export default function Home(){
	return (
		// 藍色
		<div className={styles.page}>
			<h1> Home Page </h1>
		<div>
	)
}

• 優勢：

1. 當需要復用樣式的時候，不同的組件可以import同一份樣式檔案，減少很多重復樣式代碼，減輕打包體積～
2. 說到樣式復用，CSS modules還有個特殊的composes屬性，能引入別的module的css樣式，也能重寫（override），

.page {
	composes: className from "./shared.css"
}

• 缺點：

1. 不夠“程式化” CSS modules在原生CSS的基礎上增加了以modules（檔案）劃分的作用域，解決了作用域問題，但仍逃不過在單個module內以原生的方式書寫CSS，原生的CSS只能純純的列舉出每一條樣式，如果能在書寫CSS的時候也支持一些程式特性豈不是更好？比如最常用的回圈、遍歷、函式、繼承...

CSS PREPROCESSOR 前處理器

Sass、Less、Stylus... 這些前處理器就是為了解決CSS不夠“程式化”而誕生的，他們允許你用一種不一樣的語法來寫CSS，之后再經過編譯轉化成原生CSS，

這里是一個例子：

// 只需一鍵安裝sass
$ npm install sass
// 然后把原本的css后綴檔案改成scss

// 就可以直接使用sass的方式來撰寫css啦，比如變數名、回圈、...
@ file Home.module.scss

$ primary-color: red;
$ font-stack：Helvetica

body {
	font: 100% $font-stack;
	color: $primary-color;
}

• 優勢：

1. 可以用變數、繼承、回圈、函式、...等程式特性

• 缺點：

1. 學習成本 每種前處理器都有各自特定的語法，雖然是用一種類CSS的語言來撰寫，但總有有些差異，這意味著開發人員必須配合工具掌握新的語法，
2. 樣式和專案代碼微微割裂 在解決完作用域、程式化問題后，樣式在前端專案中完完全全的獨立出來了，似乎少了一些聯動能力，既然我們有JSX這樣整合JS和HTML的合體語言，為什么不能把CSS也合體進來呢？

CSS IN JS

這是一種把CSS寫進JS的解決方案，就像把HTML寫進JS后就有了JSX，這一類的庫有styled components、emotion、jss、style tron、...

舉個使用styled jsx的例子：

import styles from '../styles/Home.module.css';

export default function Home(){
	const [color, serColor] = useState('orange');
	return (
		<div className={styles.page}>
			<style jsx>{`
				h1 {
					// 取的是組件state，可以隨state變化！
					color: ${color};
				}
			`}</style>
			<h1> Home Page </h1>
		<div>
	)
}

• 優勢：

1. 輕松能實作的程式化能力 在sass里的程式化能力，CSS in JS都能做到，甚至更強，這種方式可以直接使用JS書寫這種程式化語言，也不需要額外學習成本，
2. 創建動態樣式 在sass里，程式代碼或許和樣式檔案是完全獨立開來的，而使用CSS in JS，樣式和JS強系結，我們的樣式能夠跟著代碼、跟著組件的state等特性實作動態樣式，特別靈活！
3. 不會有作用域問題 類似module，CSS in JS的樣式只會系結在樣式定義的組件內，不會污染全域樣式～

• 缺點：

1. CSS和JS混寫，代碼管理困難，

UTILITY CLASSES 原子類

時下最火的新概念就是tailwindcss、windi css這些原子類CSS庫，能夠提供大量的原子類樣式，幫助我們快速構建樣式，

// 配置好tailwind之后
export default function Home(){
	return (
		// 在這里寫上tailwind的原子類classname，而不需要寫樣式
		<div className="text-5xl font-bold">
		<h1> Home Page </h1>
		<div>
	)
}

• 缺點

1. 需要比較麻煩的額外配置
2. 打包后，生成的HTML檔案可讀性非常非常低
3. 
4. 沒有任何的內置組件

• 優勢

1. 打包時，能自動優化，去除沒有使用的css樣式，減輕打包產物體積，

CSS FRAMEWORK

bootstrap、bulma、這一類別庫既能提供特定的樣式主題，又有內置的組件，比如bottom、cards、...等等，我個人在自己倒騰東西的時候非常喜歡用這一類框架，因為實在是太方便啦！這種方式在生產上幾乎很少采用，因為開發人員往往需要根據產品原型來繪制前端界面，而不是這些框架固定的樣式，另外采用這種方式，也容易對線上性能造成比較大影響，

// 想使用這一類框架，只用一鍵安裝上
$ npm install bootstrap

// 引入框架的樣式檔案
import 'bootstrap/dist/css/bootstrap.css'

export default function Home(){
	return (
		// 想要使用的樣式都在bootstrap中用各種classname封裝好啦，直接呼叫boostrap的預留classname，搞定
		<div className="alert alert-primary">
		<h1> Home Page </h1>
		<div>
	)
}

• 缺點：

1. 在只使用bootstrap來搭建組件和修改樣式的話，會不太方便 由于這類框架已經自帶了許多預留組件，而bootstrap的樣式又是用classname來獲取的，假設我需要頻繁使用<Bottom />組件，卻又不想在每次使用的時候，都重復的寫相同的classname，那么就會將他們封裝成<CustomButtom />，這么做的話，專案代碼中就可能會有大量的僅僅是為了封裝classname而存在的組件，
2. 打包檔案過大 整個bootstrap檔案是直接import進來的，因此在打包時，會把大量沒使用到的classname也打包進來，會造成打包產物較大～

組件庫

這是大家最熟悉的方式啦，ant design、material design、t design、rebase、....

最終落地的升級方案

不同的CSS處理方式各有優劣，在實際開發中，可以自行選擇和搭配合適的CSS處理手段，

在我目前作業中，是將專案的原生CSS，升級成css module + less 的組合，這樣既能解決當前專案的核心矛盾：作用域和樣式污染問題，又能讓CSS的撰寫程序變得更“程式”，比如使用變數、繼承等特性，

沒有使用css in js 是因為當前專案沒有主題切換和動態樣式這樣場景，此外css in js 會讓一個組件檔案變得非常冗長，尤其是目前我的作業特別多復雜圖表的封裝，僅jsx部分代碼行數已經非常長，再引入CSS代碼容易變得更混亂，我個人也更加偏向能用獨立檔案區分出CSS代碼的方式，這樣展示出更好的專案分層，

沒有使用原子類的理由就更簡單了，配置麻煩，可讀性低，而且對團隊內每個人都有較高的學習成本，不方便團隊管理，直接pass了，

在前端工程開發的程序中，面對多人協作的場景，建立標準和團隊內的規范是非常重要的一個環節，尤其當前業界的前端，就是沒有通用標準的情況下，影響專案工程穩健性的往往是缺乏規范和標準，而不是開發人員的水平，在我作業的專案中，最初就是因為大量人員流動，大家在專案中各按各自的方式寫CSS，導致在一個專案中存在3種以上CSS寫法，非常難維護，也出現了樣式互相污染、互相沖突的情況，所以才有了這次對CSS的調研，以及對專案進行升級和改造的作業，

本文轉載于：

https://juejin.cn/post/7171413795938500639

如果對您有所幫助，歡迎您點個關注，我會定時更新技術檔案，大家一起討論學習，一起進步，

標籤：其他

上一篇：JS執行機制及ES6

下一篇：JS中URLSearchParams的基本用法