[譯] 如何理智地建構複雜使用者界面如何理智地建構複雜使用者界面

<b>本文講的是[譯] 如何理智地建構複雜使用者界面，</b>

我最近在建構一個複雜、動态的 Web 應用的使用者界面（UI）。在這條路上，我學到了一些寶貴的經驗教訓。

下面的這些技巧是我希望有人在當我開始這樣一個雄心勃勃的項目之前能告訴我的。這将為我節省大量時間和精力。

複雜的 UI 通常需要你維護某種應用程式狀态。這将告訴 UI 顯示什麼内容以及如何顯示它們。 一個選擇是當使用者觸發頁面裡的某個行為的時候，立即通路這個狀态。然而據我了解，推遲改變這個應用的狀态，在目前元件的内部狀态下臨時儲存此更改會更好。

舉個例子，有一個對話框能夠讓使用者編輯某些記錄資料，比如他（她）的名字：

這時，你可能想要讓使用者每次編輯這個對話框時觸發修改。但是，我的建議是使用顯示所有資料來維護此對話框的内部狀态，直到使用者按下儲存按鈕。 此時，您可以安全地更改儲存這些記錄資料的應用程式狀态。

這樣，如果使用者決定放棄更改并關閉對話視窗，則可以直接删除元件，這時應用程式狀态保持不變。 如果你需要将資料發送到後端，便可以在一個請求中進行。 如果這些資料對其他使用者同時可用，那麼當有人編輯這些資料時其他人不會看到這些臨時值。

你的 UI 行為應該比對使用者的心理模型

當使用者使用對話框時，他們通常會認為這些記錄在完成編輯之前是不會被儲存的。元件的功能也應該比對這種行為。

使用 React/Redux 的人請注意：将一般資料儲存在 Redux Store 并使用 React 元件狀态來存儲這些臨時資料的行為是可行的。

下文中的術語「模型」指代 MVC 設計模式中的模型。

Web 應用程式中的現代 UI 在結構和行為上可能很複雜。這通常會導緻你将純粹的與 UI 相關的資料存儲在應用程式狀态之中。我的建議是将 UI 相關資料和業務資料分離。

将 UI 狀态中的業務資料和邏輯分别存儲在不同模型之中

這種方法很容易遵循和了解，因為它想讓你把業務邏輯與其他一切分離開來。這樣你的模型可以同時儲存這些資料和方法（函數）進而處理這些資料。 否則，你的應用程式可能最終會跨越多個地方穿插業務邏輯，其中最有可能是 View 元件。

例如，在應用程式中，你有一個待辦事宜的清單，并實作一個頁面來添加一個新的任務到該清單。 現在你需要在任務描述、任務日期的格式合法之前，禁用「儲存」按鈕：

普通的做法是是将需要的資料存儲在應用程式狀态的某處，并在 View 元件中編寫這樣的代碼：<code>const saveButtonDisabled = !description &amp;&amp; !date &amp;&amp; !dateIsValid(date)</code>。 但問題就出在儲存按鈕被禁用了，因為業務要求必須輸入所有的描述以及有效的日期。

是以，在這種情況下，禁用按鈕的邏輯應該放在待執行任務的模型中。 該模型可以如下表示：

現在，你可以在 View 元件中為你的 UI 邏輯使用 <code>const saveButtonDisabled = !task.isValid()</code>了。

正如你所看到的，這個提示基本上是關于如何将你的模型與MVC模式中的視圖進行分離。

如果你在一個有足夠的時間為每個功能編寫多個測試的環境中工作，這将不是問題。但我相信，大多數人并非如此。通常，你必須決定使用哪種測試。而我大多數時候會考慮內建測試，它比單元測試更有價值。

當你在代碼中修複問題時，我建議您按照以下簡單步驟操作：

寫出由于現有問題而導緻失敗的測試。如果可以通過單元測試完成，這很好。否則，使測試根據需要接觸許多代碼子產品。

在代碼庫中解決問題。

驗證測試不會失敗。

這個簡單的做法確定問題是固定且不會再發生的，因為從此之後測試将驗證它。

現代 Web 應用程式對開發人員提出了許多挑戰，UI 開發也是其中之一。 我希望本文可以幫助你避免一些錯誤，或者給你提供一個很好的話題來進一步思考和讨論。

如果能在評論中看到你對此話題的想法和發現，我将非常感激。

<b></b>

<b>原文釋出時間為：2017年6月07日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>