Нормализация избыточного состояния для REST API

Question

Рассмотрим следующую схему, вдохновленную Reddit

Я разрабатываю графический интерфейс администратора для управления пользователями, сообщениями и комментариями (подделка фактического домена здесь),Приложение React имеет различные маршруты (вкладки навигации):

• Пользователи для отображения пользователей с их сообщениями и комментариями
• Сообщения для отображения сообщенийс их комментариями (оба с учётом пользователя)

Оба маршрута также позволяют редактировать перечисленные объекты.

Я определил следующие конечные точки REST

/users
/users/{id}/posts
/users/{id}/
/posts
/posts/{id}/comments

Какя должен сформировать состояние Redux в этом случае?Должен ли я

A) Просто хранить разные типы сущностей в их собственном поддереве, сгруппированном по id?В этом случае извлечение всех сообщений или извлечение сообщений для пользователей фактически будет работать на одном поддереве.Компонент React отфильтровывает это поддерево, чтобы получать его реквизиты, когда он подходит.

B) Сформировать дерево более детально для использования с маршрутами?Например, групповые сообщения направляют сообщения по идентификатору, а пользователи отправляют сообщения по идентификатору пользователя?Это решение приведет к некоторому избыточному дублированию, пока не будут приложены дополнительные усилия для нормализации ситуации.

Answer 1

Это зависит от сложности создаваемого вами приложения.Вы прошли через https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape?

С конечных точек API похоже, что посты и пользователи довольно разобщены, а комментарии живут в контексте поста.Если это правда, это избыточное состояние может быть хорошим началом:

{
  entities: {
    posts: {
      [postId1]: [
        // comments
      ],
      ...
    },
    users: {
      [userId]: {
        posts: [postId1, postId2, ...]
      },
      ...
    }
  },
  ui: {
    screen1: {
      fetchedPosts: [postId1, postId2],
      fetchedUsers: [userId10, userId11]
    }
  }
}

entities используется в качестве локальной базы данных для извлеченных данных, в то время как ui содержит идентификаторы объектов для визуализациидля конкретных компонентов.Когда компонент выполняет выборку, данные ответа сохраняются в соответствующем объекте, тогда как идентификаторы также сохраняются в состоянии избыточности компонента.Затем в методе рендеринга компонента вы сопоставляете их.

Используя этот шаблон, вы получаете единый источник правды, можете обмениваться сущностями между компонентами, выполнять нумерацию страниц, сохранять данные.Это хороший пример для деталей реализации