时间戳

首页 > 解决方案 > 为什么 Ngrx 实体 ID 通常用作字符串？

angular - 为什么 Ngrx 实体 ID 通常用作字符串？

问题描述

我一直在寻找为 ngrx 实体设置样板的示例，并且很好奇为什么大多数人使用字符串类型 id 设置他们的模型。这很奇怪，因为对于 EntityState，选择的 id 然后存储为一个数字。在大多数情况下，我见过的例子都使用了这个，但我找不到一个合理的。

这样做有什么好处？我在想可能是为了简单的 JSON 编码，但这使得像递增索引和查找这样的正常操作很烦人。宁愿只在需要导出数据时进行编码。

这是官方仓库中示例的链接： https ://github.com/ngrx/platform/blob/master/docs/entity/adapter.md

export interface User {
  id: string;
  name: string;
}

export interface State extends EntityState<User> {
  // additional entities state properties
  selectedUserId: number | null;
}

export const initialState: State = adapter.getInitialState({
  // additional entity state properties
  selectedUserId: null,
});

标签： angularngrxngrx-storengrx-entity

解决方案

我相信在示例中：selectedUserId: number | null;是一个错误，因为他们后来将用户定义为：

export interface User {
  id: string;
  name: string;
}

也就是说，为什么使用字符串而不是数字？

1）我想获得更好的全球支持。如果人们使用将 ID 存储为数字的数据库，那么您可以将它们保存为字符串而不会出现任何问题。但是如果它是一个字符串，将它保存为一个数字会更难......

2）（这里是真正的论点）很多人正在使用 UUID 直接从前端生成一些 ID。它允许您确保 ID 是唯一的*，即使从前端生成也是如此，因此您可以离线工作（创建资源并在与后端同步之前仍然使用它），否则会非常困难。

即使您不打算在应用程序中支持离线模式，我认为还有一个更常见的用例：乐观更新。因此，您为您的资源生成一个 ID，将您的资源保存在您的 REDUX 存储中或您想要保存它的任何地方，然后请求将其添加到后端以进行 ex。如果一切都好，那就好！否则，只需在几秒钟后显示一条消息，说明无法保存资源并最终建议重试。但是每当这将起作用时，用户都会很高兴与您的应用程序进行即时交互，而不会因为网络而感到任何“滞后”。

*：它不是 100% 保证的，但是如果您阅读有关 UUID 的文章，生成已经存在的 UUID 的机会非常、非常、非常低。另外，您仍然可以在后端检查 POST 上的 ID 不存在等。

推荐阅读