為什麼Web UI開發這麼難？
source : https://itnext.io/why-web-ui-development-is-so-hard-a88c47f4b3c5 by
Web UI 開發乍一看可能很簡單，但深入研究後，您會發現許多複雜性，即使是經驗豐富的開發人員也會面臨挑戰。本文旨在剖析 Web UI 開發的固有挑戰，從 Web 語言和現代 UI 要求之間的差異，到復雜的數據管理問題和異步 API 調用。
我們還將探討經常被忽視的“不愉快的路徑”，例如加載狀態、錯誤處理以及包括安全性、性能和可訪問性的更廣泛的體系結構考慮因素。
導航語言不匹配
除非您正在構建一個簡單的、類似文檔的網頁（例如沒有搜索框或模態等高級 UI 元素的基本文章），否則 Web 瀏覽器提供的內置語言通常是不夠的。大多數 Web 應用程序比簡單的文檔複雜得多。
網絡語言與人們日常遇到的 UI 體驗之間存在巨大差異。無論是票務預訂平台、項目管理工具還是圖片庫，現代 Web UI 都很複雜，並且本地 Web 語言不容易支持它們。您可以加倍努力來“模擬”UI 組件，例如手風琴、切換開關或交互式卡，但從根本上講，您仍然在使用相當於文檔的內容，而不是真正的 UI 組件。
在理想的世界中，構建用戶界面就像與視覺 UI 設計師一起工作。C++ Builder 或 Delphi 等工具，或者 Figma 等更現代的替代品，讓您可以將組件拖放到畫布上，然後在任何屏幕上無縫渲染。
Web 開發的情況並非如此。例如，要創建自定義搜索輸入，您需要將其包裝在其他元素中，微調顏色，調整填充和字體，也許還添加一個圖標以供用戶指導。創建一個出現在搜索框正下方的自動建議列表，並與其寬度完全匹配，通常比人們最初想像的要耗費更多的人力。
上面是 Jira 票證 — 一個問題視圖，您可以看出它是一個相對複雜的用戶界面。對於這樣的 UI，您可能期望有Navigator組件、Dropdown列表Accordion等。但不存在，或者我應該直接說不存在。
開發人員努力使用 HTML、CSS 和 JavaScript 來模擬這些。如果我暫時禁用網站的 CSS，我會得到如下結果：
感謝 Jira 工程師的辛勤工作，儘管該應用程序看起來不太正常，但它仍然可以正常運行 — 您可以單擊按鈕和鏈接進行導航，甚至上傳圖像作為工單的附件。
利用設計系統庫可以緩解其中一些挑戰，為開發人員提供領先優勢，而不是從頭開始構建。然而，設計系統有其自身的一系列缺點，需要在集成到項目中之前進行徹底的評估。
不幸的是，語言不匹配只是問題的一小部分，坦率地說，自從我們有了像 React 和 Vue 這樣的聲明式 UI 庫以來，情況已經發生了輕微的變化。然而，前端領域還存在其他挑戰。數據（狀態）管理肯定在名單上。
了解狀態管理
在現代前端開發中管理狀態是一項複雜的任務。幾乎每個應用程序都必須通過網絡從遠程服務器檢索數據。這通常涉及各種問題，例如 API 訪問的身份驗證和數據獲取代碼的細節，例如使用的協議、數據格式以及 API 是 RESTful、GraphQL 還是基於 RPC。
但這只是一方面；還有管理當地國家的問題。例如，手風琴組件需要跟踪它是展開還是折疊，表單中的文本字段必須管理其自己的值。
手風琴組件
當您的應用程序達到使狀態跟踪變得困難的複雜程度時，使用 Redux 或 MobX 等第三方狀態管理庫可能會很有幫助。然而，這種方法也有其局限性，應仔細考慮。
許多開發人員傾向於使用 React 的內置 Context API 進行狀態管理。其他復雜性（例如陡峭的學習曲線、樣板代碼和潛在的性能開銷）是這些庫可能不適合所有人的一些原因。
探索不愉快的道路
當談到 UI 開發時，我們的主要關注點通常是“幸福之路” — — 一切按計劃進行的最佳用戶旅程。然而，忽視“不愉快的路徑”可能會讓你的用戶界面比你最初想像的要復雜得多。以下是一些可能導致不愉快路徑並最終使 UI 開發工作複雜化的場景。
另一個組件中的錯誤
想像一下您正在應用程序中使用第三方組件甚至其他團隊的組件。如果該組件拋出錯誤，則可能會破壞您的 UI 或導致您必須考慮的意外行為。這可能涉及添加條件邏輯或錯誤邊界來妥善處理這些錯誤，從而使您的 UI 比最初預期的更加複雜。
例如，我們嘗試訪問的以下代碼在傳入的 props 中不存在 — 一個常見的TypeError: Cannot readproperties of undefined (reading ‘doesnt’)並拋出異常。
const MenuItem = ({
item,
onItemClick,
}: {
item: MenuItemType;
onItemClick: (item: MenuItemType) => void;
}) => {
// @ts-ignore
const information = item.name + item.something.doesnt.exist;
return (
<li key={item.name}>
<h3>{item.name}</h3>
<p>{item.description}</p>
<button onClick={() => onItemClick(item)}>Add to Cart</button>
</li>
);
};如果我們不將錯誤隔離到 ErrorBoundary 中，它可能會導致整個應用程序崩潰。
下游系統出現故障
您的 UI 可能依賴於各種微服務或 API 來獲取數據。如果這些下游系統中的任何一個出現故障，您的 UI 都必須對此負責。您需要設計回退、加載指示器或友好的錯誤消息來指導用戶下一步該做什麼。有效處理這些場景通常涉及前端和後端邏輯，從而為 UI 開發任務增加了另一層複雜性。
意外的用戶行為
無論您的用戶界面設計得多麼完美，用戶總會找到以您意想不到的方式使用您的系統的方法。無論他們在文本字段中輸入特殊字符、嘗試過快提交表單，還是使用乾擾您網站的瀏覽器擴展，您都必須設計 UI 來處理這些邊緣情況。這意味著實施額外的驗證、檢查和保護措施，這可能會使您的 UI 代碼庫變得複雜。
了解並有效管理這些不愉快的路徑對於創建健壯、有彈性且用戶友好的界面至關重要。它們不僅使您的應用程序更加可靠，而且還有助於提供更全面、經過深思熟慮的用戶體驗。
我之前在這篇文章中討論過不幸的路徑，如果您還沒有閱讀過，請閱讀。
通過網絡訪問遠程狀態
在 React 中，網絡編程帶來了獨特的挑戰，超出了使用useEffect. 雖然幸福的道路可能看起來很簡單，但當您考慮錯誤處理、加載狀態和重試等各種場景時，現實很快就會變得複雜。再加上緩存的複雜性，代碼很快就會變得笨拙且難以維護。
因此，不要使用 hook 來執行此操作（儘管這是一個很好的起點）useEffect。
const [users, setUsers] = useState<User[]>([])
useEffect(() => {
const fetchUsers = () => {
fetch('https://jsonplaceholder.typicode.com/users')
.then((response) => response.json())
.then((data) => setUsers(data));
}
fetchUsers();
}, []);在現實世界的代碼庫中，除了使用 fetch 函數之外，您經常會發現自己管理其他狀態，這個過程也容易出錯。
const [loading, setLoading] = useState<boolean>(false);
const [error, setError] = useState<string>('');
useEffect(() => {
const fetchUsers = () => {
setLoading(true);
fetch('https://jsonplaceholder.typicode.com/users2')
.then((response) => {
if (response.status >= 200 && response.status <= 299) {
return response.json();
} else {
setLoading(false);
throw Error(response.statusText);
}
})
.then((data) => {
setLoading(false);
setUsers(data)
})
.catch((e) => {
setLoading(false);
setError(e);
});
}
fetchUsers();
}, []);
if(error) {
return <ErrorMessage />
}React-query文檔頁面上有一長串潛在的注意事項。
其他考慮因素
我們已經討論了 Web UI 開發中的一些關鍵挑戰，但這只是您在實際項目中遇到的複雜性的一小部分。在應對這些和其他挑戰時，必須考慮更多因素。
- 跨瀏覽器兼容性：不同的瀏覽器有不同的渲染引擎，甚至同一瀏覽器的不同版本也可能有不同的行為。這使得跨瀏覽器兼容性成為一個主要問題。
- 性能優化：確保網站快速高效需要深入了解瀏覽器如何渲染元素、延遲加載、優化資源等等。
- 輔助功能：建立一個可供所有人（包括殘疾人）使用的輔助網站，需要額外的知識和測試。
- 安全問題：隨著前端應用程序的興起，客戶端安全變得更加重要。考慮跨站點腳本 (XSS)、跨站點請求偽造 (CSRF) 和通過客戶端日誌洩露數據等問題。
雖然上面的每個公告都可以有自己的文章甚至一系列文章，但我將在這裡停下來，以免這篇文章變得過於冗長和令人難以承受。我為那些有興趣深入研究的人提供了一個參考部分，其中包含進一步的閱讀材料。
概括
總而言之，Web UI 開發領域充滿了超出編寫代碼和設計界面的挑戰。固有的語言限制、細緻入微的數據管理、異步複雜性以及經常被忽視的不愉快路徑共同使這個領域成為一個強大的領域。
圍繞安全性、性能和可訪問性的架構決策使情況進一步複雜化。了解這些挑戰是有效應對這些挑戰並打造具有視覺吸引力、強大、安全且用戶友好的 Web UI 的第一步。
