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

歐長坤發表於2017-06-07

如何理智地構建複雜使用者介面

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

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

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

理智意見 #1: 使用元件的內部狀態儲存臨時資料

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

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

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

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

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

你的 UI 行為應該匹配使用者的心理模型

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

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

理智意見 #2: 從 UI 狀態中分離模型資料

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

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

將 UI 狀態中的業務資料和邏輯分別儲存在不同模型之中

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

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

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

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

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

{
    description: 'Save Gotham',
    date: 'NOW',
    notes: 'Speak with deep voice',
    dateIsValid: () => this.date === 'NOW',
    isValid: () => this.description !== '' && this.dateIsValid()
}複製程式碼

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

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

理智意見 #3: 優先考慮整合測試而不是單元測試

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

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

依我的經驗，我瞭解到：具有良好單元測試覆蓋率的程式碼庫通常比具有良好整合測試覆蓋率的程式碼更容易出錯。我注意到開發工作引入的大多數錯誤都是軟體迴歸錯誤 (regression bug)。 單元測試通常不能很好地捕捉到這些問題。

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

  1. 寫出由於現有問題而導致失敗的測試。如果可以通過單元測試完成，這很好。否則，使測試根據需要接觸許多程式碼模組。
  2. 在程式碼庫中解決問題。
  3. 驗證測試不會失敗。

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

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

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

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃。

相關文章