一、pre

在閱讀這篇文章之前，必須要同步一個觀念就是：重視語義化是一個頂尖程序員的必備素養(yǎng)，因此很多時(shí)候你會聽到別人吐槽命名太難，其實(shí)是因?yàn)樗牧?xí)慣非常好，更希望找到完全契合場景的命名，這本身就是一件費(fèi)腦子的事情。如果這個觀點(diǎn)我們無法達(dá)成一致，那么本文的所有說法可能對你來說就顯得比較可笑。

二、痛點(diǎn)

一直以來，使用 HTML + CSS 來表達(dá) UI 結(jié)構(gòu)，都有一個若隱若現(xiàn)的痛點(diǎn)。痛點(diǎn)來源主要體現(xiàn)在 DOM 結(jié)構(gòu)的語義表現(xiàn)力不足。

例如這樣一段代碼，我們能夠很清晰的知道 DOM 結(jié)構(gòu)是怎么樣的，但是其具體的布局結(jié)構(gòu)方式和特性就不知道了。

<div>
  <div>1</div>
  <div>2</div>
  <div>3</div>
  <div>4</div>
</div>

盡管 HTML 也新增了許多語義化標(biāo)簽來彌補(bǔ)這種語義表現(xiàn)力缺失的問題，但是由于大家的應(yīng)用場景是在是很難和這些語義化標(biāo)簽非常契合的對應(yīng)上，從而導(dǎo)致了語義化標(biāo)簽的使用并不是很廣泛，到目前為止，語義化標(biāo)簽都處于一個很尷尬的境地。

<div>
  <header></header>
  <nav></nav>
  <section></section>
  <footer></footer>
</div>

導(dǎo)致語義化標(biāo)簽被廣大開發(fā)者冷淡的很大一部分原因，是因?yàn)?HTML 設(shè)計(jì)的這幾個語義化標(biāo)簽確實(shí)是不太匹配日常開發(fā)的大多數(shù)具體場景。

好在我們在使用 React/Vue/Angular 開發(fā)項(xiàng)目時(shí)，可以通過自定義組件來增強(qiáng)某一個部分的語義表達(dá)。

例如在 React 中，我們編寫一個分頁列表，你一眼就能看出來我的頁面結(jié)構(gòu)長什么樣。

<RefreshScrollView>
  <Filter />
  <Pagination />
</RefreshScrollView>

這已經(jīng)是 UI 表述的最佳實(shí)踐。但是我們也不是只看最外面這一層，當(dāng)你深入到更底層的邏輯時(shí)，最后看到的還是 div，語義表現(xiàn)力不足的事實(shí)總是存在的。

因此為了解決這個問題，在 antd 等優(yōu)秀的開源框架中，為了增強(qiáng)組件的語義表現(xiàn)力，會提供 Row Cloumn Flex Grid 等容器組件供開發(fā)者使用。

這其實(shí)是 UI 表達(dá)的最佳實(shí)踐。但是 antd 等框架對于這種思路的踐行并不是非常徹底。他沒有非常明確的建議說，我們不要使用 div 了，所以許多開發(fā)者就算使用了這種方式，也不是把它當(dāng)成最佳實(shí)踐來使用，很多時(shí)候只是為了少些兩行 css 代碼才使用他們。

很多時(shí)候也源自于 UI 組件庫本身也沒有想要去做一個大而全的布局思維重構(gòu)，從而導(dǎo)致 antd 雖然提出了這個方向和構(gòu)思，但是普通開發(fā)者也不一定能領(lǐng)會到。

HTML + CSS 語義表現(xiàn)力缺失還體現(xiàn)在結(jié)構(gòu)和樣式分離。有很大一部分開發(fā)者并不喜歡寫完結(jié)構(gòu)之后，還要重新去另外的文件給他補(bǔ)充樣式。并且這樣方式在維護(hù)的時(shí)候也并不友好，隱性的規(guī)則讓樣式的最終結(jié)果變得撲朔迷離。

最明顯的一點(diǎn)就是默認(rèn)的樣式繼承規(guī)則和樣式優(yōu)先級，這東西讓許多人在調(diào)樣式的時(shí)候非常難受。

所以很多后端來寫前端，可能他什么都能搞定，就是搞不定 css 樣式，這可太難了，哈哈哈哈。

許多開發(fā)者都意識到了這種痛點(diǎn)。因此 css in js 的方案層出不窮。原子 css 又再次重新火了起來。不過在根源上由于 HTML 文檔流的設(shè)計(jì)不夠簡潔，視覺格式化模型中涉及到的概念太多，因此最終在使用上依然會有不小的理解成本與麻煩。

例如大家在使用原子化 css 的時(shí)候，很容易會出現(xiàn)一個元素上套用了太多 class 的情況，反而導(dǎo)致可讀性極大的降低。

<!--隨意搞的一個簡易案例來說明這個問題-->
<button
  class="blue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600 text-sm text-white font-mono font-light py-2 px-4 border-2 rounded border-blue-200"
>
  Button
</button>

因此我們需要思考新的方案來解決這種場景，例如使用一個變量名來復(fù)用這些樣式。

const btn = 'blue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600 text-sm text-white font-mono font-light py-2 px-4 border-2 rounded border-blue-200'

<button class={'btn'}>
  Button
</button>

這些理念都非常好。但是原子化 CSS 畢竟不是直接編寫樣式，他的適用場景會受到很大的限制。

并且當(dāng)我們在思考如何復(fù)用原子化 CSS 的時(shí)候，其實(shí)就表示，開發(fā)者確實(shí)在期待一套完整的，全新的 UI 布局表述方式。

這就是鴻蒙應(yīng)用開發(fā)中， ArkUI 的布局思路。

在設(shè)計(jì)上，arkUI 充分吸收了 HTML 等客戶端方案發(fā)展這么多年的經(jīng)驗(yàn)教訓(xùn)，在設(shè)計(jì)上完全摒棄了文檔流的概念，轉(zhuǎn)而強(qiáng)調(diào)容器的概念。為了應(yīng)對不同的場景，arkUI 目前已經(jīng)支持了 26 種容器組件。因?yàn)槠涿鞔_的語義化，學(xué)習(xí)成本也非常低，例如如下容器組件，我們一看就能知道這是用來干嘛的。

Row
Column
Flex
Grid
List
Scroll
Swiper
Tabs
Refresh
...

并且布局方式到底是什么情況，由容器組件說了算，而不是子元素的類型說了算。

// 表示從左到右布局
Row() {
  Text('hello world')
  Text('hello world')
  Text('hello world')
}

// 表示從上到下布局
Column() {
  Text('hello world')
  Text('hello world')
  Text('hello world')
}

除了在語義化上非常重視之外，arkUI 并不支持結(jié)構(gòu)與樣式分離，而是把設(shè)置樣式的行為當(dāng)成一個 set 方法，支持一種鏈?zhǔn)秸{(diào)用的方式來做到樣式與結(jié)構(gòu)合并的最終結(jié)果。

Text('width: 10px')
  .fontSize('12fp')
  .color('#333')
  .border({
    width: '10px',
    color: Color.Red,
    style: BorderStyle.Dotted,
    radius: 15
  })

這其實(shí)是原子化 css 的進(jìn)化版。如果你覺得原子化 CSS 真香，那么這種方式的好處你也一定能夠快速理解到。

而且他比原子化 CSS 學(xué)習(xí)和記憶成本更低，更靈活，可以說是原子化 CSS 的理想化實(shí)現(xiàn)。

ArkUI 在設(shè)計(jì)上，還引入了一個風(fēng)險(xiǎn)較大的設(shè)定：樣式后置。

這個最開始是在 Swift UI 中出現(xiàn)，可能許多前端開發(fā)都沒見過。

Column() {
  Text('hello text')
    .fontSize('12fp')
    .fontColor(Color.Black)
    .fontStyle(FontStyle.Italic)
}
.width(20)
.height(20)
.border({
  width: 10,
  color: Color.Blue
})

之所以說他風(fēng)大，是因?yàn)檫@種書寫方式大家都沒見過，可能會容易給人的第一感覺就是：什么玩意兒 ...

哪怕是在 Flutter 的設(shè)計(jì)中，也是可前置可后置，然后不管是文檔案例，還是大家在開發(fā)中，其實(shí)也是讓樣式前置。

// 偽代碼
Widget build(BuildContext context) {
  return new Container(
    width: 20,
    height: 20,
    ...
    child: new Text()
  )
}

我剛開始在學(xué)習(xí) Swift 使用的時(shí)候也會擔(dān)心這種樣式后置的方式會讓樣式堆在一起比較難受，但是用了一段時(shí)間之后發(fā)現(xiàn)，真香！

我們來看一下這樣一段代碼。

Column() {
  Text(`最新值：${this.counter}`)
  Column().block()
  Column().block()
  Column().block()
    .onClick(() => {
      this.counter ++
    })
}
.margin(10)
.border({width: 4})
.width('50%')
.height('400lpx')
.justifyContent(FlexAlign.SpaceEvenly)

.block 是樣式的復(fù)用。

@Extend(Column) function block() {
  .width(40)
  .height(40)
  .backgroundColor(Color.Orange)
  .border({
    width: 2,
    color: Color.Red
  })
}

之所以我覺得真香的原因是因?yàn)槲覀冊陂_發(fā)過程中，其實(shí)子元素的樣式重復(fù)非常多，因此我們會考慮將子元素的樣式封裝起來，用一些方式來復(fù)用它。

這樣，當(dāng)我們將樣式后置之后，雖然我們依然對父元素添加了一串樣式，但是前面一部分的代碼結(jié)構(gòu)就依然非常簡潔。

以前在剛開始接觸學(xué)習(xí) Flutter 的時(shí)候，也覺得 Flutter 的 UI 表現(xiàn)形式太糟糕太復(fù)雜了，為什么不學(xué)著 JSX 那樣搞簡單一點(diǎn)，并且其他人的這個類似想法還在 github 上有非常激烈的探討。

直到后來我才理解到，這種注重語義化和容器的 UI 表達(dá)方式，可能比 JSX 更好，這才是最佳實(shí)踐。

除此之外，這種聲明式語法的編譯速度會比 JSX 更快，性能上會更好。

三、總結(jié)

鴻蒙應(yīng)用開發(fā)的 ArkUI，和基于 HTML + CSS 的 React 相比，能夠更方便的使用語義化，提倡樣式與結(jié)構(gòu)合并，并在 UI 設(shè)計(jì)上，簡化了視覺格式化模型，注重容器特性，學(xué)習(xí)理解成本得到了極大的降低，并且基于 set 的思維方式鏈?zhǔn)秸{(diào)用樣式，大膽的將樣式后置，在我個人的主觀感受里，這是一種比 React，比 Flutter 更舒適的開發(fā)體驗(yàn)。

大多數(shù)前端開發(fā)多半都有一個壞習(xí)慣，寫點(diǎn)代碼就想看看布局現(xiàn)在已經(jīng)長什么樣了，這樣其實(shí)挺影響開發(fā)效率的。你可能需要頻繁的切換或者必須要一個外接顯示器隨時(shí)預(yù)覽，反正我就是這樣。也不知道大家有沒有... 想想這是什么原因造成的吧。