懒加载

懒加载：
分页获取后台数据。
懒加载本身好实现，在页面下方放一个“加载中”控件，使用原生的intersection Observer(https://developer.mozilla.org/zh-CN/docs/Web/API/IntersectionObserver)，监听是否进入可视区，进入可视区，就让页码加1，同时监听页码，页码改变的时候重新调用后台接口，并将返回的结果追加进列表中。这个地方要加一个判断，如果页码为1，需要重置列表。
列表中包括一级文件夹和组件，数据库中把这些东西存在一起，通过isFolder字段来区分文件夹和组件，通过id和parentId构建文件夹和组件的父子关系。原本的列表加载方式是数据库一下子拿到所有的数据，并在后台组装成为父子结构。可想而知如果列表中的数据有成千上万条，那么数据的加载和渲染是非常慢的。
所以不光要做分页，还要实现在一开始只加载文件夹和单个组件，不加载文件夹中的子组件，在点击文件夹时，再请求文件夹内部的数据。
为了实现这个功能，需要修改后台获取分页数据的接口，让其不再对拿到的数据进行结构上的处理，同时需要增加一个新的接口，用于获取指定文件夹的子组件。
同时前端也需要做相应的修改。在选中文件夹时，调用后台接口拿到children数据，在当前列表中找到对应的parent，并将children塞到这个parent中。这里遗留了一个问题未解决：在点击文件夹时，数据可以顺利拿到，但是需要移动一下鼠标才能展开当前的文件夹，如果不移动鼠标，文件夹无法展开。
列表有模糊搜索功能，模糊搜索拿到的结果和以上的分页加载有所不同。模糊搜索的结果中可能包含单个组件，文件夹和文件夹中的子组件。直接拿到搜索后的结果，并将其组装成为父子结构很容易，但是如果是分页加载，就需要在SQL语句上下很多功夫，因为你需要将文件夹里的组件和文件夹摆放到一起（否则不符合前台展示的逻辑），但是数据库中的数据存储在设计时并没有考虑这一点，所以搜索实现分页加载比较困难（组长说可以实现，但是他说的时候我已经把功能重构得差不多了）
所以搜索仍然沿袭之前无分页的低效率方式，在前端的结果呈现上，有两种不同的实现，一个是使用和分页加载一样的列表，一个是单独使用一个搜索列表。基于一个这样的体验：当搜索结果清空之后，希望列表仍停留在之前滑到的位置，而不是清空所有的内容，回到第一页（这样很容易带来让用户恼火的体验）。所以搜索结果没有沿用分页加载的列表，而是单独设置了一个搜索列表。

懒加载带来的问题是：
之前对列表中的项目进行增删复制移动的逻辑，其他控件中用到列表的逻辑，几乎都与列表的加载方式有关系。所以改了加载方式之后，还要相应地修改所有与之相关的地方。
拿新增来讲，新增之后后台数据要更新，前端列表要更新，列表更新有两种实现方式。可以是临时更新，在用户下一次刷新时再拿真实的后台数据，也可以是直接刷新。临时更新需要确认插入的位置，涉及到列表的查找和插入，再加上对于组件的操作有很多，编辑功能也很复杂，所以为了避免出现某些不可预知的问题，直接刷新拿最新的后台数据比较保险。刷新完之后需要回到当前位置，所以得记录列表的scrollTop，在原本的列表中该功能也实现了，换了懒加载之后还是兼容的。但是有一点不好看的是，因为是分页加载数据，所以列表在滑动的时候会一卡一卡的，不太流畅。更加好看的写法应当是 在刷新的那一次获取数据中，根据保留的页码计算出一个pagesize，然后获取数据，这样返回的数据就会比较流畅的滑动到原来的位置上。设想一个极端的情况，页码本就到了最后一页，这样一来又和未进行懒加载时候的结果一样——渲染会很慢。所以没有进行处理。
删除复制和移动都是对于列表的更新，与新增是一致的。
还记得搜索吗，搜索使用的是另一个列表，所以如果在搜索列表中进行增删移动复制，又要进行相应的处理。这也是两个列表的劣处。搜索模式下不能只更新搜索列表，如果用户清空搜索列表回到原始列表，不能看到的是原始列表未更新的状态。所以搜索列表下增删移动复制，需要同时更新原始列表和搜索列表。
有两个地方可以删除，左上角和右上角。左上角的删除直接在本组件中进行，右上角的删除向下传递了两层，在孙组件中调用。在搜索模式下，左上角的删除可以使列表视图正常更新，右上角的却不能。这个问题尚待解决。

懒加载除了影响到列表本身，也影响到了报告中的列表显示，问题出在后台接口调用，记得我之前把分页加载接口中的组装父子结构去掉了，所以在其他地方，用到加载这个列表的地方，也得在点击文件夹时再加载其子组件。