我们应该在 Angular 模板中使用管道而不是三元条件渲染吗？答案

【问题标题】：Should we use pipes instead of ternary condition rendering in Angular templates?我们应该在 Angular 模板中使用管道而不是三元条件渲染吗？
【发布时间】：2020-08-05 05:17:03
【问题描述】：

我正在研究使用 Angular 在我的模板中执行条件的最佳方法。我的目标是避免不必要的渲染和函数调用。

我注意到，如果我的模板中有一个函数来检查并将某些内容返回到我的模板，这是错误的，因为当我有一些状态更改时，每次我做某事时都会再次调用这个函数。例如，

<div *ngFor="let user of users">
   <h3>{{ getUserRole(user.id) }}</h3>
</div>

在我的 TS 中：

getUserRole(id: number) {
   if (id === 0) {
      return 'Teacher'
   } else if (id === 1) {
      return 'Study'
   }
}

每次我在页面上执行操作时，都会调用此函数。避免这种情况的一种替代方法是使用“纯管道”。

我想知道当我在模板中使用三元条件时是否也会发生这种情况。例如，

<div *ngFor="let user of users">
   <h3>{{ user.id === 0 ? 'Teacher' : 'Study' }}</h3>
</div>

如果也出现这种情况，我什么时候需要使用管道？在所有情况下，我都需要使用示例等条件渲染某些内容，或者仅当我的条件太重（包含许多对象和属性的数组）时？

【问题讨论】：

您好，尽量避免使用行话并以尽可能简单的方式进行解释。让我知道还有什么不清楚的地方。
@veroneseComS - 不要说对不起。我完全理解你的问题。

标签： angular

【解决方案1】：

PIPES(pure) 优于内联三元运算符或调用函数，UMMM！！

为什么：-

因为管道比给定的两个更优化。使用 Pipes，Angular 将以更快的速度呈现。

原因：-

主要原因是管道的确定性。这意味着如果我定义一个函数，它没有内部状态而不是给定的--相同的输入参数--，该函数将始终产生-- 相同的输出--。这使得 Angular 可以优化并仅在输入参数发生变化时调用 transform method。

基本示例：- 我们有一个函数square()，它接受一个值并给出输入的平方值

功能：-

add(val): number{
return val*val;
}

这是我们的输入列表3, 5, 6, 6, 6, 5, 4, 3, 4, 5。（共10次）

但是 Angular 会调用 3、5、6、4 的函数内部代码。（只调用了 4 次）。

为什么？因为它为每个输入保留一份结果副本，并且如果它再次看到相同的输入，它会返回输出而不对我们的 add() 函数进行内部计算。在这种情况下，Angular 不会使用我们的 add 函数的内部代码

您的示例 user.id === 0 的真实案例？ “老师”：“学习”

对于像这些简单的计算，三元运算符可能会胜出，因为在这个例子中管道可能是多余的。

注意：-以上信息仅适用于纯管道，不适用于不纯。

【讨论】：

很好解释！供参考。如果您有一个要经常更新的列表，请记住 trackBy 功能。 trackBy 特性是 react 的一种 virtualDOM 概念。它将更新所需的 DOM，而不是整个 DOM。出于性能原因，DOM 重写根本不是首选。谢谢....
@micronyks 你好，我只给出了PIPE问题的答案。 trackBy 绝对很棒，但我们将它们与 ngFor 一起使用，而不是与管道一起使用。
是的，这只是一个旁注。

【解决方案2】：

您不应该在模板中使用函数，因为每当更改检测周期运行时，它都会反复运行该函数，这对应用程序的性能不利。
何时使用管道

当你想过滤数组或对象时。 总是首选使用纯管道。
恕我直言，如果方程不太复杂，三元也应该没问题。
最重要的

每当您在模板中使用 *ngFor 时，请务必考虑使用 ngFor 的 trackBy 功能 经常列出。
通常没有trackBy，如果你更新*ngFor列表，它会为它重新渲染整个DOM。当您处理大型数据集时，这并不好。它会影响性能。
使用 trackBy，angular 将跟踪所有元素并且仅渲染/重新渲染更新的元素。这提高了性能。

【讨论】：