Проектирование нормализованных реляционных объектов на стороне клиента с помощью декораторов Typescript? - PullRequest
Новая
       42

Проектирование нормализованных реляционных объектов на стороне клиента с помощью декораторов Typescript?

0 голосов
/ 26 октября 2018

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

Например, предположим, что у нас есть пост с хлопками, который имеет отношение один к одному.У нас может быть такой дизайн поста: 

class Post {
    clapIDs: [3423df324, 32423sdr23, 324324]
    claps: [{..}, {..}, {..}, {..}]
}

Свойство post clapIDs содержит идентификаторы, которые однозначно определяют хлопки для поста.Массив claps содержит экземпляры хлопков.

Так что, в общем, мы на самом деле не заботимся или не хотим управлять свойством clapIDs.В идеале это было бы скрыто, и мы бы аннотировали свойство claps с помощью аннотации, подобной @Column(clap_ids).

Таким образом, когда мы сохраняем сущность, она может быть сначала передана во что-то со свойством clap_ids изатем отправили по проводам с запросом REST.

Я смотрел на TypeORM , но, похоже, он ориентирован на сторону сервера, и я ищу что-то более легкое, что работает на стороне клиента.

Возможный ответ

Тип ссылки claps на сообщения может быть: 

type ClapsType = Claps[] | Claps['id'][];

А затем на Посте мы имеем: 

class Post {
    claps: ClapsType;
}

Клиент может тогдапопросить магазин разрешить / разрешить свойства с соответствующими объектами.

...