获取总类别树（所有类别及其子类别的列表）与根据需要获取每个分支？

Posted 2023-03-08

【中文标题】获取总类别树（所有类别及其子类别的列表）与根据需要获取每个分支？

【英文标题】：Fetching a total category tree (a list of all categories and their sub-categories) v.s fetching each branch as it is needed?

【发布时间】：2017-06-18 19:27:00

【问题描述】：

我不确定我的术语是否完全正确，但我的问题围绕着显示类别、子类别和子类别列表的目标。

类别、子类别和子子类别的完整数量约为 100（每个都有唯一的名称）。这个完整的类别树的任何一个分支中的最高节点数约为 10。我只需要显示这些分支中的任何一个中的每个节点的名称以及图像。

在我正在开发的 UI 类型中，这些不同的列表永远不会同时出现。

例如，当您从categories 列表中单击category 时，类别列表会消失，然后您应该会看到该类别的sub-categories 列表。当您单击sub-category 时，子类别列表消失，然后您会看到属于最近单击的sub-category 的sub-sub-categories 列表等等。

知道了这一点，我的问题是：

对基本上可以是 JSON 对象数组的“类别树”进行一次初始提取是否有任何缺点，每个对象都包含每个类别的名称和子类别等等？ （只需保留此类别树数据即可呈现我需要的任何列表）

或

我是否应该为只是初始类别进行初始提取，然后在他们单击类别后再次提取子类别列表等？ （仅在需要时获取我需要的内容）

【问题讨论】：

取决于您的要求。树有多大，你的页面在什么设备上运行，连接有多好，用户是否期望小的初始加载时间或子树之间的快速切换？

在体裁中，我喜欢尽可能多地预先加载，只要页面不会永远加载。这可以让用户在通过隧道时“导航”，减少电池消耗，并降低服务器使用/带宽

你甚至可以更进一步，将初始结果注入标记（作为<script>节点内的JSON，而不是呈现的html），你只能获取最初是第一个级别，但在后台预取更多级别。您还可以批量获取多个级别，如果事实证明，人们通常沿着这条路径导航（另一方面，如果事实证明，您应该展平树或提升这些经常使用的子子-分类到更高的级别），...但是正如 Bergi 已经说过的，这在很大程度上取决于您的数据以及您的客户偏好/行为。

大家好，感谢@Thomas 和其他人的反馈。我刚刚编辑了我的问题，并详细说明了我的用例。

【参考方案1】：

JSON 对象数组，每个对象包含每个类别的名称和子类别等

第一：名字很浅，可能会改变（随着时间的推移），可能不是唯一的，......

使用一些（永远唯一） ID。一个节点列表，每个节点都包含它的名称​​（可能会更改或重复或其他）一个唯一的 ID，它是 parentID，以及您需要的任何其他数据。使用这些数据，您可以轻松构建树。

“永远独一无二”，因为我还看到人们在结构更新后更改/清理 ID 以“消除间隙”、“ID 类似于节点的新顺序”，以及进一步的 BS。 所有这些都冒着搞乱结构的风险，实际上也搞砸了，不得不手动修复它。

类别、子类别和子子类别的完整数量约为 100（每个都有唯一的名称）。这个完整的类别树的任何一个分支中的最高节点数约为 10。我只需要显示这些分支中任何一个分支中每个节点的名称以及一张图像。

根据我的经验，这个计算对我来说并不适用。

乍一看，总共 100 个节点听起来并没有太多数据无法一次批量获取，但这仍然取决于您的节点包含多少额外数据。

对我来说没有加起来/听起来很奇怪的部分：

100 节点总数 / 10 每个类别的节点 -> 你提到的子子节点在哪里？

李>

或者，如果你真的有那么深的嵌套，而且你总共只有 100 个节点 -> 每个类别平均可能有 3-5 个节点（基于直觉的数字) 从可用性/用户的角度来看，这听起来对于太少的节点来说嵌套太多了。因此在我到达目的地之前点击（和等待）太多。 您应该考虑重组/扁平化您的结构。

所以基本上：（最多）每个类别 ^{>2 个级别}的节点总数应该超过 100 个 或者你很少使用上面提到的 10 个节点并且嵌套太多。

最后，假设它将始终保持总共 100 个节点。根据我自己的经验，这类事情往往会“扩展”超出最初定义的“绝对”;) 限制。 我有一个项目，我必须构建一个 UI 来管理一组组的此类类别树的权限。最初，这是为 10 个组和总共 30 个（嵌套）类别设计的。因此（读取+更改权限）600 个值作为（几乎永远不会满足）UI 的“绝对”限制。 当我们达到 100 个嵌套类别和 30 多个组时，整个概念、实现和可用性完全失败，并且平均而言必须在该视图中呈现近 1000 个复选框。长话短说，请记住，即使是绝对限制可能不是那么绝对，并且将来可能会超过几个数量级，这可能会破坏您此时选择的任何概念。

也许这一切似乎离题了，但它可能会影响您决定解决问题的方式，因为您最了解项目的主题、扩展的潜力、如何与客户一起做出决策，...

---

只是重复我最初的评论：

您可以将第一批数据注入到标记中，因此您无需通过额外的调用来加载它。 （作为 JSON，而不是预渲染的 HTML）

您可以在后台预加载子类别，以便用户点击链接/按钮后立即可用

您可以批量加载多个类别或级别以减少请求数量

您可以将所有这些以及您的初始方法结合起来，以满足您的需求

正如 Bergi 已经提到的，所有这一切都在很大程度上取决于您的特殊用例，一般无法回答。这就是为什么我写了这么多我的想法，以帮助您做出反思的决定。