記錄--記一次前端CSS升級_ZenDei技術網路在線

這裡給大家分享我在網上總結出來的一些知識，希望對大家有所幫助目前平臺前端使用的是原生CSS+BEM命名，在多人協作的模式下，容易出現樣式衝突。為了減少這一類的問題，提升研效，我調研了業界上主流的7種CSS解決方案，並將最終升級方案落地到了工程中。樣式衝突的原因目前遇到的樣式衝突的原因，其實根本 ...

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

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

樣式衝突的原因

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

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

調研方案

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

原生 CSS

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

缺點：

作用域問題 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;
}

打包體積大使用大量冗長的原生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>
	)
}

優勢：

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

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

缺點：

不夠“程式化” 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;
}

優勢：

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

缺點：

學習成本每種預處理器都有各自特定的語法，雖然是用一種類CSS的語言來編寫，但總有有些差異。這意味著開發人員必須配合工具掌握新的語法。
樣式和項目代碼微微割裂在解決完作用域、程式化問題後，樣式在前端項目中完完全全的獨立出來了，似乎少了一些聯動能力。既然我們有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>
	)
}

優勢：

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

缺點：

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>
	)
}

缺點

需要比較麻煩的額外配置
打包後，生成的HTML文件可讀性非常非常低
沒有任何的內置組件

優勢

打包時，能自動優化，去除沒有使用的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>
	)
}

缺點：

在只使用bootstrap來搭建組件和修改樣式的話，會不太方便由於這類框架已經自帶了許多預留組件，而bootstrap的樣式又是用classname來獲取的。假設我需要頻繁使用<Bottom />組件，卻又不想在每次使用的時候，都重覆的寫相同的classname，那麼就會將他們封裝成<CustomButtom />。這麼做的話，項目代碼中就可能會有大量的僅僅是為了封裝classname而存在的組件。
打包文件過大整個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的調研，以及對項目進行升級和改造的工作。

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