Почему идентификаторы сущности Ngrx обычно используются в качестве строки

Question

Я рассматривал примеры настройки шаблонов для сущности ngrx, и мне было любопытно, почему большинство людей настраивают свою модель с идентификатором строкового типа. Это странно, потому что для EntityState выбранный идентификатор затем сохраняется как число. По большей части примеры, которые я видел, используют это, но я не смог найти рационального.

Каковы преимущества этого? Я думал, возможно, для простого кодирования 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,
});

Answer 1

С Ngrx 4.1.0 вы можете использовать либо строковый, либо числовой идентификатор.

Просто объявите свой адаптер сущности, как показано ниже:

export const adapter: EntityAdapter<MyModel> = createEntityAdapter<MyModel>({
  sortComparer: false,
});

В этом случае у вас должен быть атрибут id либо string, либо number, например:

export type MyModel = {
  id: number,
  ...
}

Answer 2

Я полагаю, что в примере: selectedUserId: number | null; - ошибка, поскольку позже они определяют пользователя как:

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

Тем не менее, зачем использовать строку, а не числа?

1) Я думаю, для лучшей глобальной поддержки. Если люди используют базу данных с идентификаторами, хранящимися в виде чисел, тогда вы можете просто сохранить их в виде строки без каких-либо проблем. Но если бы это была строка, было бы сложнее сохранить ее как число ...

2) (и реальный аргумент здесь) многие люди используют UUID для генерации некоторых идентификаторов непосредственно из внешнего интерфейса. Это позволяет вам гарантировать, что идентификатор будет уникальным *, даже если он сгенерирован из внешнего интерфейса, и, таким образом, вы можете работать в автономном режиме (создавать ресурс и по-прежнему работать с ним до синхронизации с внутренним интерфейсом), что в противном случае было бы намного сложнее.

Даже если вы не планируете поддерживать автономный режим в своем приложении, есть более распространенный вариант использования: оптимистическое обновление. Таким образом, вы генерируете идентификатор для своего ресурса, сохраняете свой ресурс в своем магазине REDUX или там, где вы хотите его сохранить, а затем делаете запрос на добавление его в бэкэнд для ex. Если все хорошо, тогда хорошо! В противном случае просто отобразите сообщение через несколько секунд, в котором говорится, что ресурс не может быть сохранен, и в конечном итоге предложите повторить попытку. Но каждый раз, когда это будет работать, пользователь будет рад мгновенно взаимодействовать с вашим приложением, не ощущая никаких «зависаний» из-за сети.

*: это не на 100% гарантировано, но если вы читаете статьи о UUID, шансы сгенерировать уже существующий очень, очень, очень малы. Кроме того, вы можете проверить на сервере, что в POST идентификатор не существует и т. Д.