是否建议对前端的数据执行附加逻辑?

对此,有几种不同的方法。我一直推荐的第一件事是将后端处理为某种不了解前端视图的公共API。对于很多用例来说,这类问题已经解决了。如果您的API是正确构建的(并且不执行奇怪/混合/不一致的返回),返回“一切”通常是可以的。

你需要记住的第二件事是你所说的数据量。如果它是一个数据集,有1000个数组条目,对象有20个属性,不用担心-角(和JS)是相当快,你甚至不会注意到10个条目或1.000或10.000的数组之间的差异(请求大小可以发挥一个因素tho)。但是对于常规的文本返回,我们仍然只讨论kb,而今天的互联网速度并不是问题)。

下一件重要的事情是在JS和DOM中处理大型数组/对象之间存在差异。拥有一个常规的ngfor,一次显示10000个条目,绝对会减慢/延迟您的浏览器。但在这种情况下,您可以使用某种虚拟重复,如果只呈现10-50个条目(当前在DOM中可见),并且滚动时,它们只是被重用,而不是创建新条目。

最后一点是尝试编写性能检查。您说过要根据结果隐藏/显示列。如果只需要对其进行一次评估,那么尝试将其放入变量/“一次性绑定”中,而不是在每个摘要循环中检查相同的条件。如果由于检查非常复杂而需要很长时间,请尝试对可能更改值的事件作出反应,而不是检查每个摘要循环。

所以,从这篇短文中我们可以得到什么:

• 检查您的样本大小,并决定是否值得做任何事情(它有助于为业务逻辑做一些基准测试,例如迭代/解析数据)
• 尽可能多地使用JS本身。它的速度比稍后在DOM中执行它要快。如果模板是“愚蠢的”,并且只显示数据而不包含业务逻辑,那么它还有助于保持代码的干净/可读性。
• 如果您的数据变得大到可以在浏览器中处理,请考虑如何改进您的API,例如引入分页
• 最后但并非最不重要的是,进行基准测试和性能检查。在很多情况下,您只需要提高性能并编写更好/更快的代码,而不需要更改整个数据结构。

是的,这样做是明智的。但很少有情况需要考虑:

场景1:有~百万个客户,每个客户拥有~1000行数据。 在这种情况下,我们最好在客户机端进行大部分过滤,从而减少服务器上的负载,并且它可以提供更多的请求。

场景2:任意数量的客户和每个客户都拥有约10000或~百万行的数据。在这个场景中,我们必须进行服务器端分页,因为我们不应该传输整个数据。在客户端应用的每个筛选器都可能触发服务器调用以获取数据。

一般来说,客户端过滤不应该影响应用程序的性能,因为笔记本电脑/PC/框架现在可以轻松地处理负载。但是,我们不应该考虑发送大约百万行的数据,并尝试在客户端执行操作。它将影响客户端和服务器性能。