树形数据前端生成还是后台生成返回比较好？

Question

树形数据前端生成还是后台生成返回比较好？

Answer 1

1. 通常来说 生成树形结构 的处理过程放在后端是更合适的，数据量大的情况下，后端能将数据成最终状态是最理想的，前端请求数据已经经历了一次耗时的 http，如果请求到数据还需要做 结构 上的处理的话显然不太合适：

   • 虽然这种处理两个端都可以做，但我们编写程序都知道逻辑要内聚，一次数据处理中的多个处理函数，最终应该内聚到一个 api 中，需要时向外提供这个 api 即可。这种思考方式放在这里同样适用，后端负责提供数据，那么关于数据处理的过程应该内聚在后端
   • 另一个角度，假设后端不转，但这些数据最终都需要以树形结构展示，那么每个对接这个接口的前端都需要做一次数据转换，这其实是不必要的资源浪费
2. 结合当前主流的前端UI框架来看，前端拿到 树形数据 后肯定还需递归做一次 节点属性 的转换，比如树节点的业务字段是 id，title 等，不同的 UI 框架的树组件可能需要的又不一样，但适配属性的开销肯定是小于结构转换的，这部分处理放在前端问题不大，也更灵活

Answer 2

树形数据生成，存在这样的需求，通常是因为数据库是以线性表的形式保存数据，通过 parent 关系来记录树形结节关系；而前端呈现的时候需要把它转换成结构化的树形数据。

那么从数据库到前端组件，经过了哪些处理过程呢？最简单的情况：

1. 后端应用把数据从数据库读取出来，处理并交给前端
2. 前端对数据进行进一步处理呈现出来

也就是简单的前/后端两个点。这两个点都可以做线性数据向结构化数据的转换，所以有此疑问到底该在哪里做？

在没有任何提效机制的情况下，后端做就意味着每一次请求（单指需要树形的），都需要去进行一次转换，如果有 1 万次请求，就要做 1 万次转换，服务器要承担这 1 万次计算负担。如果把这个转换过程放前端，实际会把这 1 万次请求产生的转换分散到每个客户端（浏览器）去，我认为可以简单的计算为：服务器性能要有客户端性能的 1 万倍才能达到相同的时间效果。

当然实际上不会产生这么大的差异，

1. 前端不是拿机器性能来跟服务器进行比较，而是浏览器对这一个应用所分配到的性能。这个差距本身确实就很大的。
2. 服务器通常会有一些缓存和加速重算的机制，实际并不会对每一个相同的请求都再去算一次。何况对同样的请求，浏览器还有缓存机制。
3. 如果前端本身就需要对数据进行进一步加工，直接在前端合并处理，可能会减少一次处理过程。

这么说来，其实有很多点是可以做优化的。

1. 服务器加缓存，提前生成树形结构缓存起来，每次客户端请求都直接返回缓存内容。这种方式不适合每次请求的树形数据大不相同的情况
2. 浏览器缓存，在相同 URL+QueryString 的情况下，浏览器会自动缓存请求到的数据。这种情况下需要服务器响应的数据是已经处理过的。如果前端处理就不能利用这层缓存。
3. 前端使用 LocalStorage 等手段缓存，实际会减少数据的请求，这种情况下服务器返回处理前/后的数据其实不重要。
4. 如果真的都到了生产树形结构数据需要特别在意的情况下，应该考虑懒加载，即展开节点的时候再去请求 1~2 层的数据。
5. 如果数据都复杂到“换人”就可能产生不能理解业务的程度……前端处理和后端处理都解决不了这个问题，这个问题只有详尽的文档能解决。当然带类型的代码本身具有较强的自解释能力，所以强类型后端似乎更合适，不过后端也不非强类型语言，前端也有像 TypeScript 这样的类型化语言，所以这点并不是选择前/后端解决的关键。

结论……没有结论，不存在一定的哪一端处理更好，需要根据实际情况去分析优化。如果只是纯粹的想划分责任……那就看谁比较空吧。

Answer 3

个人倾向前端做，后端传列表。如果前端显示方式变了，不需要后端同步做修改。

Answer 4

1. 考虑团队水平，或者压力，前端水平高/压力小 就前端处理，反之后端
2. 总体来说考虑后端，因为后端有类型（默认前端不用ts，后端不用map或者jsonObj），处理数据更容易一些

Answer 5

我感觉还是前端处理，一般后端返回list就可以，因为我觉得前端需要的类型可能多样的，就算一个页面，不用的地方都可能需要不同结构类型

Answer 6

还是前端处理更加灵活点，但都是得看前端的能力，如果能力不足还是让后端处理吧

Answer 7

别讨论了，现实情况基本是是谁吵架厉害听谁的。

Answer 8

前后PK, 谁赢了结构以谁为准.

其实就是看水平. 一般来讲, 前端水平不如后端.