我们现在正在为我们的应用程序构建一个上下文帮助卡系统。该应用程序大量使用 ngrx，我们正在努力遵循良好做法。
我们目前正在讨论是否应该在该州存储卡片内容模板。对我来说，这似乎与 ngrx 原则有点矛盾。即模板不可序列化，可以从外部突变。但这里的问题是卡片内容可能非常复杂，并且可以有各种不同的卡片。因此，如果我们不存储模板，我们可能需要为每个案例创建一个单独的组件，并创建一个{[contentId: string]: Type<ContentComponent>}映射，以便能够引用具有字符串 ID 的组件。
首先，我想问(我猜有点固执己见的问题(——也许我的担忧是错误的，在状态中存储诸如角度模板之类的结构是正常的？
如果这不是一个非常好的解决方案，那么如何处理这样的用例？
谢谢你，很抱歉提出固执己见的问题。我知道他们在这里不是很受欢迎。
固执己见的问题需要一个固执己见的答案。我会保持简短。不要在商店中存储任何复杂对象。这不是它的用途。这是关于这个主题的好读物。
基本上商店应该提供的是：
- 为解耦组件交互提供类似可观察的模式
- 为临时 UI 状态提供客户端容器
- 提供缓存以避免过多的 HTTP 请求
- 提供多参与者并发数据修改解决方案
您还提到您的卡片内容非常复杂，并且彼此不同。那么模板绝对不是要走的路。这意味着所有逻辑都包装在一个component.ts中。似乎有点过分。
因此，组件绝对是要走的路。我可以想象，它们核心中的卡具有一些共享的功能。您可以将此功能放在抽象类中，并让卡组件扩展此类
export abstract class CardComponent {
// some shared logic
}
一些卡组件是：
@Component({...})
export class SomeCardComponent extends CardComponent {
constructor() {
super();
}
}
您关于制作包含Record<string, Type<T>>的可导出常量图的建议听起来非常可行，您可以将其与ngComponentOutlet结合使用，或者如果您想通过使用ComponentFactoryResolver进行更多控制。您可以检查这些链接中的任何一个以获得良好的实现。
您可以做到这一点的另一种方法是使用ngSwitch.
基本上，您将使用此开关拥有根模板：
<ng-container [ngSwitch]="card.id">
<some-card *ngSwitchCase="'some-card'"></some-card>
<other-card *ngSwitchCase="'other-card'"></other-card>
<!-- etc -->
</ng-container>
附带说明一下，如果您想访问父组件中的所有卡，您可以使用一个小技巧。更新卡组件以包含提供商：
@Component({
selector: 'some-card',
providers: [
{ provide: CardComponent, useExisting: SomeCardComponent }
]
})
export class SomeCardComponent extends CardComponent { //... }
在父组件中，您可以使用@ViewChildren()
@ViewChildren(CardComponent)
cardComponents: QueryList<CardComponent>;
例如，这可以派上用场，从父级访问共享逻辑。
猜我没有保持简短