菜單樹是常見的前端特效, 一般長下面這樣
還有各種形態的變種, 有長這樣的
也有長這樣的
盡管這些菜單的相貌都不盡相同, 在功能實現的本質上卻都是相同的。實現程序的大致流程如下
-
讀取服務器端的菜單數據
-
將數據轉換成html菜單結構
-
為菜單結構綁定各種交互事件,如展開、關閉等。
然而, 隨着需求的變化, 菜單往往會需要一些基礎之外的功能, 比如說添加菜單項、刪除菜單項、修改菜單名、拖拽子菜單至其它父菜單項之下等, 實現這些額外的功能將增加菜單制作的難度。就拿添加菜單項這個功能來講, 添加菜單項事件中代碼的常規實現流程如下
-
為菜單的html結構添加一個菜單項元素結點並指定節點的名稱
-
將菜單新節點數據添加至初始化菜單html結構的數據中
-
將新菜單的數據通過ajax發送至服務器端持久存儲
刪除菜單的流程亦如此
-
刪除菜單中菜單項html節點
-
刪除初始化菜單的數據中對應的數據項
-
將菜單的標識通過ajax發送至執行刪除操作的服務器端程序
這種做法不能說有問題, 但是並不完美。 尤其是對於添加菜單項功能, 當菜單項添加完成時還需要為新添加的菜單節點綁定對應的事件 , 這不但使原本只需要3步的添加操作變成了4步, 還導致了代碼邏輯的不一致、程序實現的復雜化,因為綁定事件這一步是重復的,在初始化菜單的時候執行過這項操作。 如何避免此類情況的出現呢? 其實並不難,換種思路即可。
拿添加菜單項這個功能來說, 我們完全可以使用3步操作來替代上面的4步實現操作
-
直接在菜單的數據源中添加菜單的數據項
-
重新渲染(初始化)
-
將數據發送至服務器端持久保存
這樣做程序邏輯是不是清晰了很多, 而且渲染這個操作之前就已經實現了, 現在只需要拿來用就可以了,因此看似3步的操作實質上只有2步而已, 整個過程得到了極大的簡單。 而且這種做法也適用於刪除和修改兩個功能項
刪除操作
-
刪除菜單數據中要刪除的菜單數據項,並且重新初始化菜單
-
將數據保存至服務器
修改操作
-
修改菜單數據中的需要修改的數據項,並且重新初始化菜單
-
將數據保存至服務器
如你所見, 所有對菜單的修改操作只需要針對菜單的數據源就可以了, 對菜單html元素結構的操作都可以省略掉,因為這些功能都已經包含在初始化菜單的過程中了,完全沒有多此一舉的必要再去調用一遍。
這種做法看起來有一個壞處, 就是程序比較耗費性能, 因為每次對菜單的改動都會觸發一次重新初始化菜單的操作。 事實上不必為此擔憂, 首先現代的瀏覽器對於界面的渲染優化已至極致, 其次執行一次菜單初始化操作所占用的用戶計算機資源消耗量幾乎可以忽略不計, 對於用戶體驗更是完全沒有絲毫影響 , 用戶的感觀能力遠沒有靈敏到可以感知如此微乎其微的變化。反而實現菜單代碼邏輯復雜度的降低為程序員帶來的好處卻非常明顯, 簡化邏輯的好處從開發維護時間成本到程序員的編碼體驗都會有不同程度的體現。
前端和后端不同, 前端程序消耗的資源和運行程序的機器總是一對一的, 因此性能消耗只要不是太過分, 對於用戶的影響不會很明顯 ; 而后端程序消耗的資源和運行程序的機器往往是多對一的, 只有拼命的壓榨程序的資源消耗才能降低服務器的負荷。
所以, 在開發前端程序的時候, 完全可以犧牲部分性能以達到程序邏輯的簡化目的, 這是值得的。