Как организовать частичные сущности в нормализованном редукционном магазине?

Question

Для нужд моего проекта мне нужно выбрать один из двух способов организации сущностей в редукторе.

Дело в том, что API возвращает только данные, необходимые различным представлениям для одного и того же объекта (в данном примере - автомобиля).

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

const store = {
  entities: {
    car: {
      1: {
        id: 1,
        name: "SuperCar",
        date: "1992",
        constuctor: "Super Constructor",
      },
      2: {
        id: 2,
        name: "BasicCar",
        date: "1987",
        picture: "...",
        constuctor: "Amazing Constructor",
        possessors: [3,45,34]
      }
    },
    possessors: {
      /// ...
    }
  },
  requestResult: {
    car_for_list: [2],
    car_for_home: [1, 2],
  }
}
const getCarsForHome = state => state.requestResult.car_for_home.map(id => state.entities.car[id])

Подводные камни:

• Я не знаю согласованности данных по сущности

Второй способ, который я вижу, состоит в том, чтобы рассмотреть наличие главной сущности (например, родительского класса) и использовать селекторы для получения правильных данных для представления. Главная сущность владеет всеми общими свойствами для всех представлений, а определенные сущности владеют другими.

const store = {
  entities: {
    car: {
      1: {
        id: 1,
        name: "SuperCar",
        date: "1992",
        car_for_home: 1, // key to get the details for home view,
      },
      2: {
        id: 2,
        name: "BasicCar",
        date: "1987",
        car_for_home: 2, // key to get the details for home view,
        car_for_list: 2 // key to get the details for list view
      }
    },
    car_for_home: {
      1: {
        id: 1,
        constuctor: "Super Constructor",
      },
      2: {
        id: 2,
        constuctor: "Amazing Constructor",
      }
    },
    car_for_list: {
      2: {
        id: 2,
        picture: "...",
        possessors: [3,45,34]
      }
    },
    possessors: {
      /// ...
    }
  }
}
//Selector
const getCarsForHome = state => Object.values(state.entities.car_for_home).map( car => ({ ...state.entities.car[car.id], ...car }))

Подводные камни:

• Сложно сохранить магазин в случае обновления или удаления
• Если представлению нужно отобразить новое свойство, возможно, мне придется изменить свой магазин (например, теперь car_for_list нужен конструктор, поэтому я должен сохранить его в главном car)

Итак, как лучше всего справиться с этим?

Итак, вы знаете, проект большой, производственный и масштабный.

Answer 1

Я бы сохранил состояние настолько простым, насколько это возможно, и сохранил бы его, как в первом примере.Typescript может помочь в согласованности данных, это интерфейс, который вы могли бы использовать, чтобы помочь с вашим первым примером:

Interface Car {
id: string;
name: string;
constructor: string;
pictures?: string[];
processor?: number[];
}

Сохраните свойства, которые у вас могут не быть необязательными, затем разверните их при необходимости, чтобы вы обрабатывали всеслучаи (неопределенные или заданные) везде в вашем приложении.Задача здесь состоит в том, чтобы сохранить ваши права на типы в ваших селекторах, но машинопись имеет очень хорошие выводы о типах, и если вы используете повторный выбор типов для этой библиотеки, это хорошо!

Answer 2

На мой взгляд, состояние не должно содержать логику значений (как во втором методе). Это как BDD, когда вы берете данные (например, API). Так что первый метод с селектором для сбора данных в зависимости от вашего значения - лучшее решение для меня.