家好,我是皮湯。最近業務調整,組內開啟了前端工程化方面的基建,我主要負責 CSS 技術選型這一塊,針對目前業界主流的幾套方案進行了比較完善的調研與比較,分享給大家。
目前整個 CSS 工具鏈、工程化領域的主要方案如下:
而我們技術選型的標準如下:
- 開發速度快
- 開發體驗友好
- 調試體驗友好
- 可維護性友好
- 擴展性友好
- 可協作性友好
- 體積小
- 有最佳實踐指導
目前主要需要對比的三套方案:
- Less/Sass + PostCSS 的純 CSS c側方案
- styled-components / emotion 的純 CSS-in-JS 側方案
- TailwindCSS 的以寫輔助類為主的 HTML 側方案
## 純 CSS 側方案
### 介紹與優點
> 維護狀態:一般
> Star 數:16.7K
> 支持框架:無框架限制
> 項目地址:https://github.com/less/less.js
Less/Sass + PostCSS 這種方案在目前主流的組件庫和企業級項目中使用很廣,如 ant-design 等
它們的主要作用如下:
- 為 CSS 添加了類似 JS 的特性,你也可以使用變量、mixin,寫判斷等
- 引入了模塊化的概念,可以在一個 less 文件中導入另外一個 less 文件進行使用
- 兼容標準,可以快速使用 CSS 新特性,兼容瀏覽器 CSS 差異等
這類工具能夠與主流的工程化工具一起使用,如 Webpack,提供對應的 loader 如 sass-loader,然后就可以在 React/Vue 項目中建 `.scss` 文件,寫 sass 語法,并導入到 React 組件中生效。
比如我寫一個組件在響應式各個斷點下的展示情況的 sass 代碼:
```
.component {
width: 300px;
@media (min-width: 768px) {
width: 600px;
@media (min-resolution: 192dpi) {
background-image: url(/img/retina2x.png);
}
}
@media (min-width: 1280px) {
width: 800px;
}
}
```
或導入一些用于標準化瀏覽器差異的代碼:
```
@import "normalize.css";
// component 相關的其他代碼
```
### 不足
這類方案的一個主要問題就是,只是對 CSS 本身進行了增強,但是在幫助開發者如何寫更好的 CSS、更高效、可維護的 CSS 方面并沒有提供任何建議。
- 你依然需要自己定義 CSS 類、id,并且思考如何去用這些類、id 進行組合去描述 HTML 的樣式
- 你依然可能會寫很多冗余的 Less/Sass 代碼,然后造成項目的負擔,在可維護性方面也有巨大問題
### 優化
- 可以引入 CSS 設計規范:BEM 規范,來輔助用戶在整個網頁的 HTML 骨架以及對應的類上進行設計
- 可以引入 CSS Modules,將 CSS 文件進行 “作用域” 限制,確保在之后維護時,修改一個內容不會引起全局中其他樣式的效果
#### BEM 規范
B (Block)、E(Element)、M(Modifier),具體就是通過塊、元素、行為來定義所有的可視化功能。
拿設計一個 Button 為例:
```
/* Block */
.btn {}
/* 依賴于 Block 的 Element */
.btn__price {}
/* 修改 Block 風格的 Modifier */
.btn--orange {}
.btn--big {}
```
遵循上述規范的一個真實的 Button:
```
<a class="btn btn--big btn--orange" href="#">
<span class="btn__price"></span>
<span class="btn__text">BIG BUTTON</span>
</a>
```
可以獲得如下的效果:
#### CSS Modules
CSS Modules 主要為 CSS 添加局部作用域和模塊依賴,使得 CSS 也能具有組件化。
一個例子如下:
```
import React from 'react';
import style from './App.css';
export default () => {
return (
<h1 className={style.title}>
Hello World
</h1>
);
};
```
```
.title {
composes: className;
color: red;
}
```
上述經過編譯會變成如下 hash 字符串:
```
<h1 class="_3zyde4l1yATCOkgn-DBWEL">
Hello World
</h1>
```
```
._3zyde4l1yATCOkgn-DBWEL {
color: red;
}
```
CSS Modules 可以與普通 CSS、Less、Sass 等結合使用。
## 純 JS 側方案
### 介紹與優點
> 維護狀態:一般
> Star 數:35.2K
> 支持框架:React ,通過社區支持 Vue 等框架
> 項目地址:https://github.com/styled-components/styled-components
使用 JS 的模板字符串函數,在 JS 里面寫 CSS 代碼,這帶來了兩個認知的改變:
- 不是在根據 HTML,然后去寫 CSS,而是站在組件設計的角度,為組件寫 CSS,然后應用組件的組合思想搭建大應用
- 自動提供類似 CSS Modules 的體驗,不用擔心樣式的全局污染問題
同時帶來了很多 JS 側才有的各種功能特性,可以讓開發者用開發 JS 的方式開發 CSS,如編輯器自動補全、Lint、編譯壓縮等。
比如我寫一個按鈕:
```
const Button = styled.button`
/* Adapt the colors based on primary prop */
background: ${props => props.primary ? "palevioletred" : "white"};
color: ${props => props.primary ? "white" : "palevioletred"};
font-size: 1em;
margin: 1em;
padding: 0.25em 1em;
border: 2px solid palevioletred;
border-radius: 3px;
`;
render(
<div>
<Button>Normal</Button>
<Button primary>Primary</Button>
</div>
);
```
可以獲得如下效果:
還可以擴展樣式:
```
// The Button from the last section without the interpolations
const Button = styled.button`
color: palevioletred;
font-size: 1em;
margin: 1em;
padding: 0.25em 1em;
border: 2px solid palevioletred;
border-radius: 3px;
`;
// A new component based on Button, but with some override styles
const TomatoButton = styled(Button)`
color: tomato;
border-color: tomato;
`;
render(
<div>
<Button>Normal Button</Button>
<TomatoButton>Tomato Button</TomatoButton>
</div>
);
```
可以獲得如下效果:
### 不足
雖然這類方案提供了在 JS 中寫 CSS,充分利用 JS 的插值、組合等特性,然后應用 React 組件等組合思想,將組件與 CSS 進行細粒度綁定,讓 CSS 跟隨著組件一同進行組件化開發,同時提供和組件類似的模塊化特性,相比 Less/Sass 這一套,可以復用 JS 社區的最佳實踐等。
但是它仍然有一些不足:
- 仍然是是對 CSS 增強,提供非常大的靈活性,開發者仍然需要考慮如何去組織自己的 CSS
- 沒有給出一套 “有觀點” 的最佳實踐做法
- 在上層也缺乏基于 styled-components 進行復用的物料庫可進行參考設計和使用,導致在初始化使用時開發速度較低
- 在 JS 中寫 CSS,勢必帶來一些本屬于 JS 的限制,如 TS 下,需要對 Styled 的組件進行類型注釋
- 官方維護的內容只兼容 React 框架,Vue 和其他框架都由社區提供支持
整體來說不太符合團隊協作使用,需要人為總結最佳實踐和規范等。
### 優化
- 尋求一套寫 CSS 的最佳實踐和團隊協作規范
- 能夠擁有大量的物料庫或輔助類等,提高開發效率,快速完成應用開發
## 偏向 HTML 側方案
### 介紹與優點
> 維護狀態:積極
> Star 數:48.9K
> 支持框架:React、Vue、Svelte 等主流框架
> 項目地址:https://github.com/tailwindlabs/tailwindcss
典型的是 TailwindCSS,一個輔助類優先的 CSS 框架,提供如 `flex` 、`pt-4` 、`text-center` 、`rotate-90` 這樣實用的類名,然后基于這些底層的輔助類向上組合構建任何網站,而且只需要專注于為 HTML 設置類名即可。
一個比較形象的例子可以參考如下代碼:
```
<button class="btn btn--secondary">Decline</button>
<button class="btn btn--primary">Accept</button>
```
上述代碼應用 BEM 風格的類名設計,然后設計兩個按鈕,而這兩個類名類似主流組件庫里面的 Button 的不同狀態的設計,而這兩個類又是由更加基礎的 TailwindCSS 輔助類組成:
```
.btn {
@apply text-base font-medium rounded-lg p-3;
}
.btn--primary {
@apply bg-rose-500 text-white;
}
.btn--secondary {
@apply bg-gray-100 text-black;
}
```
上面的輔助類包含以下幾類:
- 設置文本相關: `text-base` 、`font-medium` 、`text-white` 、`text-black`
- 設置背景相關的:`bg-rose-500` 、`bg-gray-100`
- 設置間距相關的:`p-3`
- 設置邊角相關的:`rounded-lg`
通過 Tailwind 提供的 `@apply` 方法來對這些輔助類進行組合構建更上層的樣式類。
上述的最終效果展示如下:
可以看到 TailwindCSS 將我們開發網站的過程抽象成為使用 Figma 等設計軟件設計界面的過程,同時提供了一套用于設計的規范,相當于內置最佳實踐,如顏色、陰影、字體相關的內容,一個很形象的圖片可以說明這一點:
TailwindCSS 為我們規劃了一個元素可以設置的屬性,并且為每個屬性給定了一組可以設置的值,這些屬性+屬性值組合成一個有機的設計系統,非常便于團隊協作與共識,讓我們開發網站就像做設計一樣簡單、快速,但是整體風格又能保持一致。
TailwindCSS 同時也能與主流組件庫如 React、Vue、Svelte 結合,融入基于組件的 CSS 設計思想,但又只需要修改 HTML 上的類名,如我們設計一個食譜組件:
```
// Recipes.js
import Nav from './Nav.js'
import NavItem from './NavItem.js'
import List from './List.js'
import ListItem from './ListItem.js'
export default function Recipes({ recipes }) {
return (
<div className="divide-y divide-gray-100">
<Nav>
<NavItem href="/featured" isActive>Featured</NavItem>
<NavItem href="/popular">Popular</NavItem>
<NavItem href="/recent">Recent</NavItem>
</Nav>
<List>
{recipes.map((recipe) => (
<ListItem key={recipe.id} recipe={recipe} />
))}
</List>
</div>
)
}
// Nav.js
export default function Nav({ children }) {
return (
<nav className="p-4">
<ul className="flex space-x-2">
{children}
</ul>
</nav>
)
}
// NavItem.js
export default function NavItem({ href, isActive, children }) {
return (
<li>
<a
href={href}
className={`block px-4 py-2 rounded-md ${isActive ? 'bg-amber-100 text-amber-700' : ''}`}
>
{children}
</a>
</li>
)
}
// List.js
export default function List({ children }) {
return (
<ul className="divide-y divide-gray-100">
{children}
</ul>
)
}
//ListItem.js
export default function ListItem({ recipe }) {
return (
<article className="p-4 flex space-x-4">
<img src={recipe.image} alt="" className="flex-none w-18 h-18 rounded-lg object-cover bg-gray-100" width="144" height="144" />
<div className="min-w-0 relative flex-auto sm:pr-20 lg:pr-0 xl:pr-20">
<h2 className="text-lg font-semibold text-black mb-0.5">
{recipe.title}
</h2>
<dl className="flex flex-wrap text-sm font-medium whitespace-pre">
<div>
<dt className="sr-only">Time</dt>
<dd>
<abbr title={`${recipe.time} minutes`}>{recipe.time}m</abbr>
</dd>
</div>
<div>
<dt className="sr-only">Difficulty</dt>
<dd> · {recipe.difficulty}</dd>
</div>
<div>
<dt className="sr-only">Servings</dt>
<dd> · {recipe.servings} servings</dd>
</div>
<div className="flex-none w-full mt-0.5 font-normal">
<dt className="inline">By</dt>{' '}
<dd className="inline text-black">{recipe.author}</dd>
</div>
<div class="absolute top-0 right-0 rounded-full bg-amber-50 text-amber-900 px-2 py-0.5 hidden sm:flex lg:hidden xl:flex items-center space-x-1">
<dt className="text-amber-500">
<span className="sr-only">Rating</span>
<svg width="16" height="20" fill="currentColor">
<path d="M7.05 3.691c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.372 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.539 1.118l-2.8-2.034a1 1 0 00-1.176 0l-2.8 2.034c-.783.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.363-1.118L.98 9.483c-.784-.57-.381-1.81.587-1.81H5.03a1 1 0 00.95-.69L7.05 3.69z" />
</svg>
</dt>
<dd>{recipe.rating}</dd>
</div>
</dl>
</div>
</article>
)
}
```
上述食譜的效果如下:
可以看到我們無需寫一行 CSS,而是在 HTML 里面應用各種輔助類,結合 React 的組件化設計,既可以輕松完成一個非常現代化且好看的食譜組件。
除了上面的特性,TailwindCSS 在響應式、新特性支持、Dark Mode、自定義配置、自定義新的輔助類、IDE 方面也提供非常優秀的支持,除此之外還有基于 TailwindCSS 構建的物料庫 Tailwind UI ,提供各種各樣成熟、好看、可用于生產的物料庫:

因為需要自定的 CSS 不多,而需要自定義的 CSS 可以定義為可復用的輔助類,所以在可維護性方面也是極好的。
### 不足
- 因為要引入一個額外的運行時,TailwindCSS 輔助類到 CSS 的編譯過程,而隨著組件越來越多,需要編譯的工作量也會變大,所以速度會有影響
- 過于底層,相當于給了用于設計的最基礎的指標,但是如果我們想要快速設計網站,那么可能還需要一致的、更加上層的組件庫
- 相當于引入了一套框架,具有一定的學習成本和使用成本
### 優化
- Tailwind 2.0 支持 [JIT](https://blog.tailwindcss.com/tailwindcss-2-1 "JIT"),可以大大提升編譯速度,可以考慮引入
- 基于 TailwindCSS,設計一套符合自身風格的上層組件庫、物料庫,便于更加快速開發
- 提前探索、學習和總結一套教程與開發最佳實踐
- 探索 styled-components 等結合 TailwindCSS 的開發方式
## 參考鏈接
- [CSS 工程化發展歷程](https://bytedance.feishu.cn/docs/doccnTRF0OZtJMgKuo3y0hIDMbc# "CSS 工程化發展歷程")
以上便是本次分享的全部內容,希望對你有所幫助^_^
喜歡的話別忘了 分享、點贊、收藏 三連哦~
歡迎關注公眾號 程序員巴士,來自字節、蝦皮、招銀的三端兄弟,分享編程經驗、技術干貨與職業規劃,助你少走彎路進大廠。
很長的一段時間中,Vue 官方都以簡單上手作為其推廣的重點。這確實給 Vue 帶來了非常大的用戶量,尤其是最追求需求開發效率, 往往不那么在意工程代碼質量的國內中小企業中,Vue 占據的份額極速增長。但是作為開發者自身,我們必須要認清一個重點,簡單易用從來不應該在技術選型中占據很大的份額,可維護性才是。
以防萬一有的同學實在不看官方文檔,我先提一嘴,SFC 就是寫 Vue 組件的時候寫的.vue文件,這一個文件就是一個 SFC,全稱 Single File Component,也即單文件組件。
在開始說我個人的觀點之前,我們先來看幾個事實:
一是:Vue3 的定義原生支持 JSX,并且 Vue3 源碼中有jsx.d.ts來便于使用 JSX。 不知道同學們看到這里會想到什么, 我的第一反應是:社區對于 JSX 的需求聲音是不小的,所以會反向推動 Vue3 官方對于 JSX 的支持。
二是:AntDesign 的 vue3 版本,基本全部都是用 JSX 開發的,而且 Vue3 現在官方的 babel-jsx 插件就是阿里的人一開始維護的, 雖然我向來不喜歡阿里系的 KPI 推動技術方式,而且現在的 JSX 語法支持也不是很符合我的期望,但至少在使用 JSX 開發是更優秀的選擇這點上,我還是很認可 AntDesign 團隊的。
OK,說這些呢,主要是先擺出一些事實作為依據,讓有些同學可以不需要拿什么:
這些觀點來批斗我,首先我都會從客觀的角度來分析為什么,至少是我是能講出優劣勢的理由的。
OK,前言差不多到這里,接下來咱給您分析分析,為什么你應該選擇 JSX 來開發 Vue。
其實第一點就已經是殺手了,對于想要使用 TypeScript 來開發 Vue3 應用的同學來說,這簡直就是 SFC 無法克服的世界難題。
一句話概括:TypeScript 原生支持 JSX 語法,而基本無望 TS 官方能支持 SFC 的 template 語法。
TS 毫無疑問在前端社區的重要性越來越大,但凡未來對于代碼質量有一定要求的前端團隊,都應該會選擇使用 TS 來進行開發。 而且現在基本上在 NPM 上都能看到包你都能找到對應的 TS 定義,現在使用 TS 開發成本已經只剩下你是不是會 TS 語法了,在這種情況下是否支持 TS 則是開發模式在未來走不走的遠的重要原因。
目前 SFC 只能通過shim讓 TS 可以引入.vue文件,但是對于所有 SFC 的組件的定義都是一樣的:
declare module '*.vue' {
import { DefineComponent } from 'vue'
const component: DefineComponent<{}, {}, {}, any>
export default component
}
也就是說你引入的 SFC 組件,TS 是不知道這個組件的 Props 應該接收什么的。所以你無法享受到這些 TS 的優勢:
當然你會說既然 Vue 官方能開發處 SFC 的語法,自然會支持這些特性。我表示這當然有可能,但是這個難度是非常大的,需要很多方面的支持,甚至可能需要 TS 官方團隊愿意協助, 但是我想不到 TS 官方有什么理由來支持 SFC,因為這只是 Vue 自己創建的方言,在其他場景下是沒有使用的,TS 是面向全社區的,我覺得他們不會考慮主動來支持 SFC。
那么有同學要問了,JSX 不也是非原生的 JS 語法么,他怎么就能讓 TS 官方支持了呢,是不是 FB 和微硬之間有什么 PY 交易?
這就涉及第二點了,JSX 和靜態模板的靈活性區別。
很多人弄錯了一個問題,就是覺得 SFC 的模板語法和 JSX 是一樣的,都是一種別人發明的語法,并不是 JS 原生的。這是事實,但又有一些區別,這個區別主要是體現在對于 JSX 的認知上。
一句話概括:JSX 并沒有擴展 JS 的語法,他只是縮略了 JS 的寫法!其本質就是 JS 的語法糖
就像 es6 給增加的語法糖,比如
const a = 1
const b = 2
const obj = { a, b }
// 其實就等價于
const obj = { a: a, b: b }
這種寫法并沒有擴展 JS 的能力,只是簡便了寫法,JSX 也是一樣的。
JSX 其實就是方法調用,他和 JS 是有一對一對應關系的,我們來看一個例子:
const element = <div id="root">Hello World</div>
這里的 JSX 語法編譯之后其實就是:
const element = createElement('div', { id: 'root' }, 'Hello World')
而 JSX 就是這些了,沒有什么更多的內容,所以說 JSX 只是方便我們寫嵌套的函數調用的語法糖,而其本身沒有擴展任何其他的內容。
但是 SFC 就不一樣了。
SFC 定義的不僅是語法,更是文件。
SFC 的具體定義是單文件組件,它本身就是把一個文件看作一個單位,所以他的約束性是要大很多的,你必須具有固定的文件結構才能使用 SFC,這做了很多的限制:
我們一點點來講
這個說實話非常非常不方便,很多時候我們寫一個頁面的時候其實經常會需要把一些小的節點片段拆分到小組件里面進行復用(如果你現在沒有這個習慣可能就是因為 SFC 的限制讓你習慣了全部寫在一個文件內)。
React 生態中豐富的 css-in-js 方案就是很好的例子,我們可以通過:
const StyledButton = styled('button', {
color: 'red',
})
如果我們這個頁面需要使用特定樣式的按鈕,通過這種方式在頁面文件里面封裝一下是非常常見的。因為沒必要把這個組件拆分出去,他也不是一個可復用的組件,拆分出去了還要多一次import。
Vue 生態基本沒有 css-in-js 的成熟方案其實跟這個限制也很有關系。
再來一個例子,比如我們封裝了一個 Input 組件,我們希望同時導出 Password 組件和 Textarea 組件來方便用戶根據實際需求使用,而這兩個組件本身內部就是用的 Input 組件,只是定制了一些 props:
const Input = { ... }
export default Input
export const Textarea = (props) => <Input multiline={true} {...props} />
export const Password = (props) => <Input type="password" {...props} />
在 JSX 中可以非常簡單地實現,但是如果通過 SFC,你可能就要強行拆成三個文件,另外為了方便,你可能還要增加一個index.js來導出這三個組件,你能想象這多了多少工作量么。
我不知道有多少同學看過 Vue 的 template 編譯出來之后的代碼,以我的經驗來說看過的可能不會超過 50%(樂觀估計),建議同學們如果還不了解的,可以去嘗試看一下。
為什么要看這個呢?因為你看了之后你會發現,你在 template 里面寫的類似 HTMl 的內容,其實跟 HTML 根本沒啥關系,他們也會被編譯成類似 JSX 編譯出來的結果。
{
render(h) {
return h('div', {on: {}, props: {}}, h('span'))
}
}
類似這樣的結果,而這里面h函數調用的結果就是一個 VNode,是 Vue 中的節點的基礎單元。那么既然這些單元就是一個對象,其實理所當然的,他們是可以作為參數傳遞的。 也就是說,理論上他們是可以通過props把節點當作參數傳遞給其他組件的。
這個做法在 React 中非常常見,叫做renderProps,并且其非常靈活:
const Comp = () => <Layout header={<MyHeader />} footer={<MyFooter />} />
但是因為 SFC 模板的限制,我們很難在 SFC 里面的 props 上寫節點:
<template>
<Layout :header="<MyHeader/>"></Layout>
</template>
這樣寫是不行的,因為 SFC 定義了:header綁定接受的只能是 js 表達式,而<MyHeader/>顯然不是。
因為通過 props 傳遞不行,所以 Vue 才發明了 slot 插槽的概念
雖然我們一直再說 Vue 簡單,但是事實上ScopedSlots一度成為新手理解 Vue 的噩夢,很多同學都被這個繞來繞去的作用域整的死去活來。
我們看一個ScopedSlots的例子:
<template>
<Comp>
<template v-slot:scope="ctx">
<div>{{ctx.name}}</div>
</template>
</Comp>
</template>
這里ctx是Comp里面的屬性,通過這種方式傳遞出來,讓我們在當前組件可以調用父組件里面的屬性。這簡直就是理解的噩夢,但是如果用 JSX 實現類似功能就非常簡單:
<Comp scope={name => <div>{name}</div>} />
我們只是給一個叫做scope的 props 傳遞來一個函數,這個函數接受一個name屬性,在Comp里面會調用這個函數并傳入name。 簡單來說我們傳入的就是一個構建節點片段的函數,就是這么簡單。
這就是因為 SFC 的模板的限制,導致靈活性不足,Vue 需要去創造概念,創造關鍵字來抹平這些能力的不足,而創造的概念自然就引入了學習成本。
所以其實我一直不認可 Vue 比 React 好學的說法的,如果你真的認真研究所有用法,并且總是嘗試用最合理的方式實現功能,那么 Vue 絕對不會比 React 簡單。
這個體現在兩個方面,一個是我們定義在全局的一些固定數據如果要在組件內使用的話,就要通過this掛載到組件上。
比如我們緩存了一份城市數據,這種數據基本上是不會改的,所以也沒必要掛載到組件上讓其能夠響應式。但是在 SFC 里面這是做不到的, 因為模板的執行上下文是在編譯時綁定。你在模板里面訪問的變量,都會在編譯時自動綁定到this上,因為模板需要編譯,其本身也是字符串不具有作用域的概念。
而這在 JSX 中則不復存在:
const citys = []
const Comp = () => {
return citys.map(c => <div>{c}</div>)
}
另外一個方面則是在組件使用上,在 SFC 中,組件必須事先注冊,因為我們在模板里面寫的只能是字符串而不能是具體某個組件變量。 那么模板中的組件和真實的組件對象只能通過字符串匹配來實現綁定。這帶來了以下問題:
在 JSX 中則沒有這些問題,因為 JSX 里面直接使用組件引用作為參數:
const Comp = {...}
const App = () => <Comp />
其實上面能看出來,除了 SFC 本身的問題之外,Vue 使用字符串模板也會帶來很多的靈活性問題。 最直接的證據,就是 Vue 使用了directive來擴展功能(當然這不是 Vue 發明的,老早的模板引擎就有類似問題)。
為什么說directive是不得已的選擇呢?因為靜態模板缺失邏輯處理的能力。我們拿列表循環舉例,在 JS 中我們可以非常方便地通過map函數來創建列表:
const list = arr.map(name => <span key={name}>{name}</span>)
而因為 JSX 本身就是函數調用,所以上面的代碼和 JSX 結合起來也非常自然:
const App = () => (
<div>
<Header />
{arr.map(name => (
<span key={name}>{name}</span>
))}
</div>
)
上面的例子對應到 JS 如下:
const App = () =>
createElement('div', {}, [
<Header />,
arr.map(name => createElement('span', { key: name }, name)),
])
這仍然是因為 JSX 只是 JS 的語法糖的原因,所有能在 JS 中實現的在 JSX 里面都能實現。
而 SFC 的模板是基于字符串編譯的,其本身就是一段字符串,我們不能直接在模板里面寫map來循環節點,(當然我們可以在可以接收表達式的地方寫,比如v-on里面)。
那么我們不能循環節點,有需要這樣的功能來渲染列表,怎么辦呢?就是發明一個標志來告訴編譯器這里需要循環,在 Vue 中的體現就是v-for指令。
同學們可能要問了,既然 Vue 能實現v-for,為什么不直接實現表達式循環列表呢?他當然也可以實現,但是他肯定不會這么選,因為成本太高了。 他要這么做就相當于他要實現一個 JS 引擎,而其實里面很多內容又是不必須的,一個v-for其實就能夠適用大部分情況了。
但有了v-for就需要v-if,那么后面還會需要其他各種能力,這就是一種方言的產生和發展的過程。
當然指令也不僅僅是 JS 表達式的代替品,其本身也是增加了一些其他能力的,比如它能夠讓我們更方便地訪問 DOM 節點, 但是嘛,我們用框架的理由不就是為了能夠盡可能的屏蔽 DOM 操作嘛~
以上就是我對應該選擇使用 JSX 還是 SFC 進行開發的分析,其實歸根到底 SFC 的問題在于其沒有擁抱 JS, 他的語法是自己發明的,他需要有一個 JS 實現的 compiler 來讓其最終能在 JS 環境中運行,這本質上就是一種發明, 我們不能否認發明確實有優點,但我們也不能只看有點不看問題,沒能擁抱 JS 自然就很難完全復用 JS 社區的優勢 而 JS 社區一直在蓬勃發展,好用的工具一直在涌現,而 SFC 想要使用 JS 社區的這些工具還要自己再實現一份,我們可以細數以下 SFC 做了哪些兼容
基本上常用的工具我們都需要等待 Vue 社區或者官方開發了插件之后才能運行。而 JSX 因為有 babel 和 typescript 的官方支持, 基本上所有新的 JS 生態工具原生都是支持的。
在這 Vue3 開始預備發力的階段,我們還是希望 Vue 社區能夠使用更優秀更規范的方式來進行開發, 其實如果我們直接使用 JSX 開發 Vue3,我們會發現很多時候我們都不需要用到emit、attrs這些概念, 甚至如果 Vue3 的 JSX 插件支持,我們甚至能夠拋棄slots。
但是因為 Vue3 一定要考慮兼容 Vue2,導致本身潛力很好的 Vue3 總是顯得縮手縮腳,這不得不說是一種遺憾。
者:小迷妹
轉發鏈接:https://mp.weixin.qq.com/s/49mJuvEEv5L9x3y0a5lRWw
*請認真填寫需求信息,我們會在24小時內與您取得聯系。