【譯】UI工程的元素

在我以前的文章中，我討論了關於咱們存在知識漏洞問題。大家也許會總結爲我提倡平庸，並非，這是很寬的領域。

我堅信你能從任何地方開始學習，而且不須要聽從特定的順序。可是獲取足夠的經驗仍是有很大的價值的。我我的已經對建立用戶界面很是感興趣了。

我一直在思考我真正瞭解和認爲有價值的是什麼。固然，我熟悉一些技術（好比JavaScript和React）。但更重要的經驗教訓是難以捉摸的。我從未試圖用語言表達出來。這是我第一次嘗試將它們羅列出來而且對它們進行描述。

---

市面上有不少關於技術或庫的學習路線。哪一個庫將在2019流行？2020又會是什麼？你應該學習Vue或者React嗎？Angular？Redux或者Rx嗎？你須要學習Apollo？REST或者GraphQL嗎？這是很容易迷茫的。若是做者錯了呢？

我學習的最大突破不是學習一門固定的技術。而是，當我在解決一個特定的UI問題時學到了不少。有時，我會在以後發現一些庫或者同伴幫助了我。在其餘狀況下，我會想到本身的解決方案（好的或者壞的）。

理解問題、嘗試使用解決方案、應用不一樣的策略，這些組合使得我獲取了最具價值的學習經驗。這篇文章主要就是探討這些問題的。

---

若是你主要工做於用戶頁面，你可能處理了很多這樣的挑戰——直接的或使用庫。不管如何，我鼓勵你建立一個不依賴庫的小應用，而後進行復現和解決這些問題。它們都沒有一個正確的解。學習來自於探索問題領域和嘗試不一樣可能的權衡。

🤔列舉出頁面開發中的一些問題，本身思考解決

---

• 一致性（Consistency）。 你點擊了「like」按鈕後，文本變成了：「你和你另外的三個朋友喜歡了這篇文章。」你再此點擊，文本又變回去了。聽起來很簡單吧。可是在屏幕上好幾個地方都存在這樣的標籤。也許有一些其餘的提示須要改變（例如按鈕的背景色）。‘likers’列表已經提早從服務端獲取到了，而且當鼠標移上去的時候也應該可以看到你的名字了。若是你導航到另外一個屏幕並返回，博客不該該「忘記」它被喜歡過。即便是局部一致性自己，也會帶來一些挑戰。可是其它的用戶可能也會改變咱們展現的一些數據（例如喜歡咱們正在看的帖子）。咱們怎樣保證屏幕上不一樣部分同步相同的數據呢？咱們如何以及什麼時候使本地數據與服務器一致，反之亦然？
• 響應性（Responsiveness）。 人們只能在有限的時間內忍受他們的行爲缺少反饋。對於手勢和滾動等連續性操做，這個限制很低。(即使是跳過一個16ms的幀也會讓人感受很「不爽」。)對於像點擊這樣的離散操做，有研究代表，用戶認爲任何小於100ms的延遲都很快。若是一個動做須要更長的時間，咱們須要顯示一個視覺指示器。但也有一些違反直覺。致使頁面佈局的「跳躍」或經歷幾個加載階段的指示器會讓動做感受比之前更慢。相似地，在20ms內處理交互(以丟幀爲代價)比在30ms內處理交互要慢，並且沒有刪除幀。大腦並非基準。咱們如何保證咱們的應用響應不一樣的輸入呢？
• 延遲（Latency）。 計算和網絡連接都須要時間。有時，若是不影響目標設備的響應能力，咱們能夠忽略計算成本（確保在低配的設備上測試過你的應用）。可是處理網絡延遲是無可避免的——它將消耗幾秒鐘！咱們的應用不能靜止等待數據或代碼加載。可是那有可能發生在每個屏幕中。如何在不顯示「loading」加載或空白狀況下優雅地處理延遲呢？如何避免「跳躍」佈局呢？以及如何在每次不「從新鏈接」代碼的狀況下更改異步加載項呢？
• 導航（Navigation）。 當咱們與頁面交互時，咱們指望UI可以保持「穩定」。事物不該該就在咱們眼前消失。導航，不管是在應用程序內部啓動（如單機連接），仍是因爲外部事件（如單擊「後退」按鈕），都應該聽從這一原則。例如，在配置文件屏幕上的/profile/likes和/profile/following選項卡之間切換不該該清除選項卡視圖以外的搜索輸入。儘管導航到另外一個屏幕中就像走進了一間房間同樣。人們指望可以走回去並能找到他們留下的東西。若是你在導航中，單擊一個連接，而後返回，你失去了在導航中的位置，這是使人沮喪的——或者等待它再次加載。咱們如何在不丟失重要上下文的狀況下設計應用程序來處理任意導航。
• 陳舊（Staleness）。 經過引入本地緩存，咱們可使「後退」按鈕導航當即生效。在緩存中，咱們能夠「記住」一些數據，以便快捷訪問，即便理論上咱們能夠從新獲取它。可是緩存自身也存在着一些問題。緩存可能會過時。如何處理當我改變了一個頭像，緩存也應該會更新的問題。若是我建立了一篇新的文章，也應該當即出如今緩存中，不然緩存將是無效的。這將變得困難且容易出錯。若是發佈失敗了呢？緩存在內存中停留多長時間？當咱們從新獲取提要時，是將新獲取的提要與緩存的提要「整合」，仍是將緩存丟棄？如何在緩存中表示分頁或排序？
• 熵（Entropy）。 熱力學第二定律是這樣說的，隨着時間的推移，物質會變得一團糟（嗯，不徹底是）。這也一樣適用於用戶界面。咱們不能準確地預測用戶交互及其順序。在任什麼時候間點，咱們的應用程序可能處於數量驚人的狀態下。咱們盡最大努力使結果可預測而且限制咱們的設計。咱們不想看到一個bug截圖，而後疑惑「這是怎樣發生的？」。對於N個可能的狀態，它們之間有N*(N - 1)個可能的躍遷。例如，若是一個按鈕能夠處於5種不一樣的狀態之一（正常，激活，懸停，危險，禁用），對於5×4=20個可能的轉換，更新按鈕的代碼必須是正確的——或者禁止其中一些。咱們如何控制可能狀態的組合爆炸，並使視覺輸出可預測？
• 優先級（Priority）。 有些事情比其它事情更重要。對話框可能出如今產生它的按鈕的「上方」，並「跳出」其內容的剪輯邊界。新調度的任務(例如響應單擊)可能比已經啓動的長時間運行的任務(例如在屏幕摺疊下方呈現下一篇文章)更重要。隨着咱們應用程序的成長，它的部分代碼是由不一樣的人和團隊編寫的，它們爭奪有限的資源，如處理器、網絡、屏幕空間和包大小預算。有時您能夠根據「重要性」的共享級別對競爭者進行排序，好比CSS z-index屬性。可是它不多有好的結局 每一個開發人員都偏頗地認爲他們的代碼很重要。若是一切都很重要，那麼什麼都不重要!咱們如何讓獨立的小部件合做，而不是爭奪資源?
• 可訪問性（Accessibility）。 沒法訪問的網站不是一個小衆問題。例如，在英國，每5我的中就有1人患有殘疾。（這是一張不錯的信息圖表）我也有這種感受。雖然我只有26歲，但我仍是很難閱讀字體細、對比度低的網站。我試着減小使用觸控板的次數，我擔憂有一天我將不得不經過鍵盤來瀏覽功能不佳的網站。咱們須要讓咱們的應用程序對於有困難的人來講不那麼可怕——好消息是有不少唾手可得的成果。首先是教育和工具。但咱們也須要讓產品開發人員作正確的事情。咱們能夠作些什麼來使易訪問性成爲默認而不是過後考慮?
• 國際化（Internationalization）。 咱們的應用程序須要在全世界各地運行。人們不只會說不一樣的語言，並且咱們還須要用產品工程師最少的工做量來支持從右到左的佈局。咱們如何在不犧牲延遲和響應性的狀況下支持不一樣的語言？
• 交付（Delivery）。 咱們須要將應用程序代碼發送到用戶的計算機。咱們使用什麼傳輸和格式?這聽起來很簡單，可是這裏有不少權衡。例如，本機應用程序傾向於提早加載全部代碼，代價就是使得應用程序變得更大。Web應用程序的初始負載每每較小，但在使用過程當中會有更多的延遲。咱們如何選擇在哪一個點引入延遲？咱們如何基於使用模式優化咱們的交付？最優解須要什麼樣的數據？
• 伸縮性（Resilience）。 若是你是昆蟲學者你可能會喜歡bugs，但你可能不喜歡看到它們出如今你的程序中。然而，你的一些bug將不可避免地進入生產環境。而後會發生什麼？一些bug會致使錯誤但定義良好的行爲。例如，你的代碼可能在某些條件下顯示不正確的輸出。可是若是渲染代碼崩潰了呢?那麼咱們就不能有意義地繼續，由於視覺輸出會不一致。一個帖子的崩潰不該該「拉下」整個feed，也不該該讓它進入一個致使更多崩潰的半中斷狀態。咱們如何編寫代碼來隔離渲染和獲取失敗，並保持應用程序的其他部分運行？容錯對於用戶界面意味着什麼？
• 抽象（Abstraction）。 在一個小的應用程序中，咱們能夠硬編碼許多特殊的狀況來解決上述問題。可是應用程序每每會增加。咱們但願可以重用、分叉和聯接代碼的各個部分，使它們可以一塊兒工做。咱們想在不一樣的人熟悉的片斷之間定義清晰的界限，避免使常常變化的邏輯過於僵化。咱們如何建立隱藏特定UI部分實現細節的抽象？咱們如何避免在咱們的應用增加過程當中再次引入咱們剛剛解決的問題？

---

固然，還有不少我沒有提到的問題。這個列表毫不是詳盡的!例如，我沒有談到設計人員和工程協做，或者調試和測試。也許下一次我會寫的更詳盡。閱讀關於這些問題的文章時，很容易想到使用特定的視圖庫或數據獲取庫做爲解決方案。可是我鼓勵你僞裝這些庫不存在，從這個角度再讀一遍。您將如何解決這些問題?去試試構建一個小的應用程序吧!(我很樂意看到你在GitHub上作的實驗——你能夠發推特（Twitter）回覆我。)

這些問題的有趣之處在於，它們中的大多數都能以任何規模出現。你能夠在諸如typeahead或工具提示這樣的小工具中看到它們，也能夠在諸如Twitter和Facebook這樣的大型應用程序中看到它們。

想一想你喜歡使用的應用程序中的一個非試驗性的UI元素，仔細檢查一下這個問題列表。您能描述一下它的開發人員所選擇的一些折衷方案嗎?嘗試從頭建立一個相似的行爲!

經過在不使用庫的小型應用程序中試驗這些問題，我學到了不少關於UI工程的知識。我向任何想對UI工程中權衡利弊的人推薦一樣的方法。

說明💡：翻譯👉Dan Abramov🤩的文章是一件很愉悅的事情，樂在其中並樂此不疲。但因爲我的能力有限，一些翻譯的很差的地方或者理解不對的地方，但願發現問題的同窗能指出，共同窗習！

原文連接：overreacted.io/the-element…