zTree 是一個依靠 jQuery 實現的多功能 “樹插件”。使用zTree會涉及到一些操作的邏輯，例如增加節點、刪除節點等，下面我簡要描述一下實際使用中的一點心得。
zTree的節點json設計（也就是你后台的數據庫設計）可以采用以下設計格式，每一個節點由id、pId、level、name等字段構成，另外可添加一個relation字段來表示各節點直接的聯系，例如一級節點（id為1）可作0.，二級節點可作0.1.（以‘.’號結尾）。其它的node格式可參考zTree官網demo www.treejs.cn/v3/main.php#_zTreeInfo：
var zNodes =[{id:1, pId:0, level:1, name:"test", open:true}];
有了上述的格式后便可開始實際的操作了，比如異步獲取數據（async，此setting在zTree的官方api上有對應內容），當然我們現在要講的內容是對節點的操作，對其它內容不做拓展，請讀者自行查閱zTree官方文檔。
假設有API（以Restful API設計格式）：
1. POST /api/node
2. GET /api/nodes
...
對於新增節點來說，存在着新增根節點與新增子節點兩種情況：
對於新增根節點，父節點為0，層級為1，將節點對應的data={pId:0,level:1,name:'xxx}通過ajax或其它手段使用POST api路徑（POST /api/node）向后台請求即可（id應該不重復，mysql可設置自增，mongodb本身則生成一條id不重復的文檔）；
對於新增子節點，父節點為上一級節點id，層級為父節點層級加1，下一步新增操作如上新增根節點一致。
新增節點的邏輯大致如下：
對於獲取樹節點，這里有一個點容易弄混，就是樹的作用。對於樹來說，它應該只作為一個數據的索引，而不是說通過請求后台api就要將所有的data（你想展示的內容，或者說你的業務邏輯需要用到的數據）都在樹上展示出來（如果需要將data展示出來為什么不能直接用循環來將data放置在多個div塊呢？）。樹展示的節點應該盡量簡潔，例如zTree官網展示的demo只顯示了節點的名稱。
那么此時讀者可能會問：那么對應節點的數據應該怎么展示呢？
這個問題可以用兩種方式來解答，第一，如果在向后台請求時（GET /api/nodes），返回的json存在data，那么則在點擊zTree上節點時（點擊時提供一個回調函數，函數的參數其中之一即為當前節點的信息），可通過各種形式模態框、iframe內嵌的頁面或你想使用的dom形式來展示對應節點的信息。
第二，可以通過對應節點的id來發起請求例如（/api/node/1），以此來獲得對應節點的信息。
對於以上兩種形式，個人比較推崇后者。生成樹時只需要一些很簡單的字段（id，pid，name等），考慮這種情況，我們想要生產的樹的節點映射的是一個個文檔，那么假設文檔（doc）除了上述簡單字段外還有content、status，doc_html等其它內容。
站在生成樹的角度來說，使用第一種方式，如果在獲取節點時，直接將節點的所有字段全數返回，那么很明顯對於生成樹是很冗余的，並且當doc的content或doc_html內容較長，大小過大時必然會影響樹的生成性能，本來10ms的事弄成需要100ms就得不償失了。
另一方面，使用第二種方式，對於獲取節點信息或操作信息本身和生成樹就是處在不同的業務范圍內，不應該放在同一個維度上來處理；並且在獲取信息時，不同的操作需要用到的信息也會不同，例如當查看doc信息時，只需要看到doc_html、當修改doc信息時，需要使用到content、status等信息；基於原子操作，當使用第一種方式時，如果文檔doc_a是公用的，有兩個人在一段很短的時間內操作該文檔（假設A用戶、B用戶均已打開頁面並在操作期間沒有進行頁面刷新），A用戶在查看doc_a而B用戶在修改doc_a，當B用戶在修改doc_a完成后，A用戶點擊doc_a對應節點，顯然A用戶並沒有獲取到更新后的doc_html，而使用第二種方式則能通過發起請求獲取到修改后的數據信息。
以上就是我向討論一點點內容，才疏學淺，請各位指教，另外如果希望看一下對應的內容可以看我的github的PDoc（前端使用的樹不是用的zTree，用的是element-ui的樹但是大同小異，后台用的node，歡迎各位star，各位提issue，各位拍磚~），下附地址：