1

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

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

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

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

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

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

或者

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

4

1 回答 1

2

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

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

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

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

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

根据我的经验，这个计算并不适合我。

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

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

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

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

所以基本上：
要么应该有超过 100 个节点，每个类别>2 级别（最多） 10 个节点， 要么你很少使用提到的 10 个节点并且嵌套太多。

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

    长话短说，请记住，即使是绝对限制也可能不是那么绝对，并且将来可能会超过几个数量级，这可能会破坏您此时选择的任何概念。

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

只是重复我最初的评论：

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

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

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

  • 你可以结合所有这些，以及你最初的方法来满足你的需求

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

于 2017-02-01T22:45:03.843 回答