前幾篇：

• Ant Design 4.0 的一些雜事兒 - Table 篇
• Ant Design 4.0 的一些雜事兒 - Form 篇

聊完了 Table 和 Form 兩個重型組件，我們來繼續聊聊看起來不那么重的 Select 組件。它在 Ant Design 4.0 中有哪些變化。如果你讀過 《Ant Design 4.0 進行時》，那你應該已經有了大概的印象。當然，即便沒有讀過也不用擔心。之后會為你細細道來 Select 背后的一些故事~

“滾滾的車輪”

如果你關注過底層實現，你會發現 rc-select 和 rc-tree-select 在選擇框部分有大量相似而又有一點點不同的地方。這有一段有趣的歷史，當年先有的 Select 組件之后結合了 Tree 做了一個 TreeSelect 組件。由于這兩個組件有少部分代碼相同，所以 TreeSelect 復制了一部分 Select 的代碼，繼續開發。但是隨著時間推移，兩者自分裂之日起，來自社區的 issue 以及人類的忘性。兩者新增的一些 API 開始出現了矛盾。

一個典型例子就是 inputValue 和 searchValue 之爭：

最早，Select 和 TreeSelect 對于搜索框內的文字都不支持受控模式。之后社區提了 issue 希望對其進行控制，于是乎 rc-select 就多了一個 inputValue 。

然后又過了一段時間，社區同學提出 TreeSelect 的搜索框內容在選擇一個值后會被清空。這在單選沒有問題，但是如果是多選的話，就會遇到需要重復輸入搜索內容的情況。嗯嗯，這的確不好。于是我們就在 3.7.0 版本中添加了 autoClearSearchValue。

那么，既然 TreeSelect 有了。Select 也應該有啊。于是在 3.10.0 里我們給 Select 也添加了 autoClearSearchValue 。

你們發現問題了嗎？rc-select 把搜索框的值叫做 inputValue 但是自動清除卻叫做 autoClearSearchValue。因為兩個 API 各自發展最后又合到了一塊兒。

于是，我們在之后的版本進行了調整，統一使用 searchValue ，而遺留的 inputValue 在之后的版本會收到 warning 信息。

樣式誰為先？

如果你是一個設計師，你會發現 v3 版本的 Select 和 TreeSelect 在單選開啟搜索的時候樣子有點不太一樣：

TreeSelect 搜索框在下面

Select 搜索框在同級

于是我就去做了一下考古。發現在 0.12.x 版本中，Select 的輸入框是在彈窗內部的：

而在之后 1.x 版本中，Select 改成了現在的設計，但是 TreeSelect 卻沒有更新。 于是乎，TreeSelect 隨著 0.12.x 的尾巴一直保留了這個設計。

我們在 issue 中對此有所討論。從 v3 的設計角度來說，下拉框內包含搜索框更容易讓用戶明白這個輸入框是用于搜索而非當前的值。但是在 v4 中，我們經過討論認為 Select 作為一個更加常用的組件。用戶已經培養了使用習慣，搜索框位置已經不再是一個會讓人糾結的問題。所以新版設計中，改為 TreeSelect 的搜索框移出于 Select 保持一致。

多米諾骨牌

Select 底層的 rc-select 有著非常古老的歷史，追溯到第一次提交是 2015 年 1 月。 當年，React 還是 0.12.x 的版本。大家對生命周期的理解也不像現在擁有大量文章進行介紹。所以一些陳年代碼片段因為一直運行良好就保留至今，其中一個困擾大家很久的是一段不知道為什么直接設置 state 的代碼。 @Mack 在編寫測試的時候，看到它毅然決然寫下了一個注釋：

對啊，為啥不用 `setState`？

@陳帥等13w人 在重構成 Typescript 的時候，看到它，毅然決然的改成了 setState：

事后，我們獲得了一個 bug：

https://github.com/ant-design/ant-design/issues/14262

于是， @陳帥等13w人 默默進行了回滾并添加了額外的 comment：

當然，我們在重寫代碼的時候已經拋開了這些歷史包袱。在 v4 版本中，Select 沒有這些直接操作 state or DOM or style 的臟代碼。轉而使用純粹的生命周期來進行管理，以準備迎接未來的 concurrent 模式。

誰先誰后

在日常維護生活中，我們還收到過一個 issue：

https://github.com/ant-design/ant-design/issues/17630

第一反應估計大家都是 onChange 然后清空一下 value，但是正如我們上面所說的。AutoComplete 實際上是一個輸入框。所以用戶輸入的時候是會觸發 onChange 的，所以在 AutoComplete 中如果要觸發選擇應該使用 onSelect 事件。 但是，我們的順序是先 onSelect 后 onChange 。這導致，如果用戶用 onSelect 清空了值，又會被 onChange 給賦值回來。于是，我們做了調整，onChange 變成了最先觸發的。小伙伴本終于可以輕松的通過其他事件來修改 value 啦~

原生的不香嗎？

原生的 select 組件簡單好用。不過如果你想要實現一些額外的效果，它卻又不盡如人意。我們暫時不提 Option 不能接受 ReactNode 這類問題。先來一個簡單的例子，如果你為原生的 select 設置一個空值，你會期望頁面中是一個空選項：

<select value=""><option>one</option> </select>

而實際上卻是：

更麻煩的是，原生的 select 由于會默認設置一個值到選項里。所以如果你的 select 只有一個 option 時，你就無法觸發 onChange 了。

為此，大部分使用原生 select 組件為了保留空值不得不提供一個補位：

此外，如果你的 select 需要多選，select 會從一行變成多行展示。其對應的 onChange 事件獲得的 value 也不是你所預期的。

為此，幾乎每一個組件庫總是會著手解決 Select 組件的問題。 將其進行提煉、抽象變得簡單、好看且“好用”。

value 的同步問題

在我們的日常維護中，一個關于 value 的常見提問就是：“為什么 value 不在 options 中卻可以展示。這是一個 bug！”

的確，它的行為和原生的 select 不太一樣，但是這其實是有意為之。從交互角度看，如果你給一個組件賦值。那么無論是用戶還是開發者，都會存在一個預期。即：

• 用戶：我看到了 Select 的值為 a，我不需要打開這個 Select 看一圈 options ，我也知道它的值是 a。
• 開發者：我為這個 Select 設置了值為 a，那么我應該對我賦的值負責。組件不應該在我的預期外修改這個值。

這是一個很有趣的問題，試想一下有個 Select ，它的 options 是異步加載的。那么在其 value 加載完成且 options 還沒有準備好的時候。你預期 Select 的值應該是什么？很顯然，如果是沒有值，那么受控的 value 就和展示的值不同步了。更有甚者，如果你的 options 是依賴于另一個控件來動態加載。那么你的 Select 值就會反復處于 value => null => value 的狀態。對于用戶而言，它處于即是有值又是無值的狀態。 即便我并不是想設置這個 Select，我只是打開這個頁面看看配置而已。

所以，無論 options 是什么狀態。Select 的展示值與其內部值都應該跟隨 value 受控。

combobox 是不是一個 Select？

在 v3 初期，我們的 Select 提供了一個 combobox 模式，你可以理解為現在的 AutoComplete 組件。combobox 模式下，Select 相當于一個 Input 組件，只是它提供了一個自動完成的下拉選項卡，其輸入框內的值就是 value。

但是，這也正是讓人困擾的地方。開發者很難分清 combobox 模式到底和其他的模式有什么區別：

于是，我們不得不反復告知 combobox 設計上的區別：

然后收獲了

為此，我們最終決定將 combobox 從 Select 中抽離出來。轉成一個新的組件 AutoComplete。它雖然在內部與 Select 共享了大量代碼，但是仍然毅然決然的與 Select 分道揚鑣以降低開發者的理解成本。

雜談：我們推薦你可以看一下今年 SEE Conf 中 @林外 關于 《Ant Design 4.0：創造快樂工作》的演講。Ant Design 對于組件設計會保持克制，因而我們會從設計與實現的角度共同去探索一個組件所代表的意義。也正是于此，AutoComplete 應該與 Select 進行拆分以達到開發者更好的開發體驗。減少困擾就是減少工作量，減少工作量就是早點下班~

選擇生成器

上面我們已經描述過了 TreeSelect 和 Select 在選擇框部分非常相似，而 API 更是幾乎 70% 都相同。在解決了布局樣式統一的問題后，我們終于可以將這一部分進行提煉。

在新版的 rc-select 中，我們抽取了一個 generate 方法。它主要接收一個 OptionList 的自定義組件用于渲染下拉框部分。這樣我們就可以直接復用選擇框部分的代碼，而自定義 Select 和 TreeSelect 對應的列表或者樹形結構了。

鍵盤的小把戲

為了讓 Selct 更貼近原生組件，我們需要考慮到一些鍵盤交互的問題。它應該有且唯一有一個能獲取焦點的元素來進行交互處理，否則就會遇到 Tab 到 Select 時需要多次 Tab 才能切換到下一個組件的問題。也會遇到 v3 時期，DatePicker 中 onFocus 和 onBlur 多次觸發的問題：

因而在設計之初，我們給 Select 預留了一個全組件唯一的焦點入口 input。這個 input 在設置 showSearch 的時候，是那個搜索框；在未設置的時候，是一個 opacity: 0 的幽靈元素；在禁用時，它只需要一個 disabled 就可以略過鍵盤交互。 從而我們將一些組合的鍵盤操作簡化為了對 input 的操作，我們不再需要面對多個焦點組件之間進行焦點的切換。

v3 中打開面板按 ESC 會導致焦點無法還原的問題

此外，我們還對鍵盤交互進行了一些細節調整。

比如在 v3 版本中，通過 tab 選中 Select 后必須通過 Space 或 Enter 打開下拉框才能進行輸入過濾。在 v4 版本中，利用 input 總是存在的特性。獲取焦點的 Select 可以直接輸入觸發過濾，減少了用戶額外的操作步驟。

又如 v3 中，多選模式下長按刪除鍵會出現把已經選中的值誤刪的情況。在新版中，我們為此添加了一個額外的狀態來確定你是否正在輸入。如果是輸入狀態，刪除至最左時不會觸發刪除選中值的操作。當停止輸入一段時間后，釋放該狀態以允許用戶刪除：

v3 的手抖誤刪

v4 的輸入檢測防止誤刪

同樣的，我們將這套規則也應用于 Tree 組件上。v4 版本的 Tree 也擁有一個隱藏且唯一的焦點組件用于處理鍵盤交互。更 Cool 的是，由于這個焦點組件是無法被鼠標點擊的。從而我們可以精確的知道，其交互是來自于用戶點擊還是鍵盤聚焦：

Tree 擁有鍵盤 only 的交互樣式

看到這里，你或許會想到一個問題。既然下拉內容是自定義的，那么如何確定自定義內容支持哪些操作呢？其中的奧秘在于，我們規定的 OptionList 需要提供一個鍵盤交互接口。在上層 Select 消費完畢后仍有未處理的鍵盤事件則會通過該接口傳遞給 OptionList。也因此，我們可以完全復用 rc-tree 組件自身已經完成的鍵盤交互。

差不多了~

是的，又到了結尾的時候。這次文章本來還想寫一寫 Tree 更多的故事，不過只是作為一部分的話又略為可惜。其中 Ant Design 支持動畫的虛擬滾動技術可以額外寫一篇大文章，讓大家理解我們為了一些交互細節額外做了什么事情。而它和 Tree 也非常有關系。所以，這里就不做重復功。下次有機會我們再細聊吧。

PS：雖然這里不提虛擬滾動。但是 Select 也已經接入了虛擬滾動，你可以通過這個例子體驗一下 v3 與 v4 版本的性能差異。

總結

以上是生活随笔為你收集整理的easyui根据select下拉框内容更新表单内容_Ant Design 4.0 的一些杂事儿 - Select 篇的全部內容，希望文章能夠幫你解決所遇到的問題。

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