懶載入：
分頁獲取後臺資料。
懶載入本身好實現，在頁面下方放一個“載入中”控制元件，使用原生的intersection Observer(https://developer.mozilla.org/zh-CN/docs/Web/API/IntersectionObserver)，監聽是否進入可視區，進入可視區，就讓頁碼加1，同時監聽頁碼，頁碼改變的時候重新呼叫後臺介面，並將返回的結果追加進列表中。這個地方要加一個判斷，如果頁碼為1，需要重置列表。
列表中包括一級資料夾和元件，資料庫中把這些東西存在一起，通過isFolder欄位來區分資料夾和元件，通過id和parentId構建資料夾和元件的父子關係。原本的列表載入方式是資料庫一下子拿到所有的資料，並在後臺組裝成為父子結構。可想而知如果列表中的資料有成千上萬條，那麼資料的載入和渲染是非常慢的。
所以不光要做分頁，還要實現在一開始只加載資料夾和單個元件，不載入資料夾中的子元件，在點選資料夾時，再請求資料夾內部的資料。
為了實現這個功能，需要修改後臺獲取分頁資料的介面，讓其不再對拿到的資料進行結構上的處理，同時需要增加一個新的介面，用於獲取指定資料夾的子元件。
同時前端也需要做相應的修改。在選中資料夾時，呼叫後臺介面拿到children資料，在當前列表中找到對應的parent，並將children塞到這個parent中。這裡遺留了一個問題未解決：在點選資料夾時，資料可以順利拿到，但是需要移動一下滑鼠才能展開當前的資料夾，如果不移動滑鼠，資料夾無法展開。
列表有模糊搜尋功能，模糊搜尋拿到的結果和以上的分頁載入有所不同。模糊搜尋的結果中可能包含單個元件，資料夾和資料夾中的子元件。直接拿到搜尋後的結果，並將其組裝成為父子結構很容易，但是如果是分頁載入，就需要在SQL語句上下很多功夫，因為你需要將資料夾裡的元件和資料夾擺放到一起（否則不符合前臺展示的邏輯），但是資料庫中的資料儲存在設計時並沒有考慮這一點，所以搜尋實現分頁載入比較困難（組長說可以實現，但是他說的時候我已經把功能重構得差不多了）
所以搜尋仍然沿襲之前無分頁的低效率方式，在前端的結果呈現上，有兩種不同的實現，一個是使用和分頁載入一樣的列表，一個是單獨使用一個搜尋列表。基於一個這樣的體驗：當搜尋結果清空之後，希望列表仍停留在之前滑到的位置，而不是清空所有的內容，回到第一頁（這樣很容易帶來讓使用者惱火的體驗）。所以搜尋結果沒有沿用分頁載入的列表，而是單獨設定了一個搜尋列表。

懶載入帶來的問題是：
之前對列表中的專案進行增刪複製移動的邏輯，其他控制元件中用到列表的邏輯，幾乎都與列表的載入方式有關係。所以改了載入方式之後，還要相應地修改所有與之相關的地方。
拿新增來講，新增之後後臺資料要更新，前端列表要更新，列表更新有兩種實現方式。可以是臨時更新，在使用者下一次重新整理時再拿真實的後臺資料，也可以是直接重新整理。臨時更新需要確認插入的位置，涉及到列表的查詢和插入，再加上對於元件的操作有很多，編輯功能也很複雜，所以為了避免出現某些不可預知的問題，直接重新整理拿最新的後臺資料比較保險。重新整理完之後需要回到當前位置，所以得記錄列表的scrollTop，在原本的列表中該功能也實現了，換了懶載入之後還是相容的。但是有一點不好看的是，因為是分頁載入資料，所以列表在滑動的時候會一卡一卡的，不太流暢。更加好看的寫法應當是 在重新整理的那一次獲取資料中，根據保留的頁碼計算出一個pagesize，然後獲取資料，這樣返回的資料就會比較流暢的滑動到原來的位置上。設想一個極端的情況，頁碼本就到了最後一頁，這樣一來又和未進行懶載入時候的結果一樣——渲染會很慢。所以沒有進行處理。
刪除複製和移動都是對於列表的更新，與新增是一致的。
還記得搜尋嗎，搜尋使用的是另一個列表，所以如果在搜尋列表中進行增刪移動複製，又要進行相應的處理。這也是兩個列表的劣處。搜尋模式下不能只更新搜尋列表，如果使用者清空搜尋列表回到原始列表，不能看到的是原始列表未更新的狀態。所以搜尋列表下增刪移動複製，需要同時更新原始列表和搜尋列表。
有兩個地方可以刪除，左上角和右上角。左上角的刪除直接在本元件中進行，右上角的刪除向下傳遞了兩層，在孫元件中呼叫。在搜尋模式下，左上角的刪除可以使列表檢視正常更新，右上角的卻不能。這個問題尚待解決。

懶載入除了影響到列表本身，也影響到了報告中的列表顯示，問題出在後臺介面呼叫，記得我之前把分頁載入介面中的組裝父子結構去掉了，所以在其他地方，用到載入這個列表的地方，也得在點選資料夾時再載入其子元件。