相比算法,我認為數據結構和設計模式對前端更重要,原因有三:
1)JS原生能提供的數據類型確實有限。很多時候我們用對象和數組簡單粗暴的解決問題,寫壹堆復雜的業務代碼來支撐邏輯。
比如我們要做壹個輪播,自然會想到用數組來記錄輪播圖片的列表數據。我們這裏比較時髦,用vue數據驅動視圖的思路來實現。我們需要在每次輪播翻頁的時候改變數組中圖片的順序,看起來沒問題。但是當業務比較復雜的時候,比如我們需要支持循環回放和雙向回放,就需要對數組的邊界值進行特殊的判斷,降低了代碼的可維護性。
所以如果我們換個角度想,壹開始不使用數組定義圖片列表,而是使用鏈表?問題就簡單多了。但是鏈表的數據結構不是js原生實現的,需要我們自己完成。
因此,有必要掌握常用的數據結構及其相關方法。
2)設計模式是在特定情況下對問題的優雅解決方案。我在這裏大膽而優雅。是的,壹個問題往往有不止壹個答案。
例如,我想將click事件綁定到頁面上的壹系列按鈕,並要求按鈕的內容在被單擊時彈出。壹個簡單粗暴的方法是給每個按鈕添加壹個onclick事件。假設按鈕的數量非常大或者有其他點擊事件要在這個按鈕上執行,這個方案就不那麽可行了。壹些學生想到了使用事件委托,是的,這裏妳使用了壹個設計模式,代理模式。孰優孰劣壹目了然。
我認為每個業務場景都有壹個合適且優雅的解決方案,這就是設計模式。
3)壹般來說,前端要處理的數據量和計算復雜度都不高。比如我想求壹個數組中的最大值,壹般我會直接使用數組的排序方法,而不考慮自己寫壹個氣泡或者快速行。如果真的要處理大量的數據,這個處理過程是否應該放在前端恐怕是值得商榷的。
問題是需要不斷抽象的,抽象的程度與經驗和能力成正比。