Как следует использовать избыточное хранилище в больших реактивных приложениях?

Question

В настоящее время я создаю приложение для реагирования на электронную коммерцию, где пользователи могут продавать принадлежащие друг другу вещи. Типичный рабочий процесс с точки зрения пользователя для создания и управления рекламой может выглядеть следующим образом: пользователь создает объявление -> объявление загружается в базу данных -> пользователь извлекает свои объявления из базы данных и просматривает их в списке -> он решите что-то изменить в объявлении, щелкните по нему и получите форму с данными объявления (извлеченными из базы данных), которые можно редактировать.

Моя проблема здесь в том, что я действительно не понимаю, что держать в избыточном количестве? Цель избыточности - упростить поток данных, там должны храниться данные, необходимые для нескольких компонентов. Но если я всегда получаю нужные мне данные из базы данных (например, когда пользователь выбирает список своих объявлений или рекламные данные, которые можно редактировать), разве это не лишний шаг, тогда ненужный шаг?

Я хочу быть последовательным в своем коде о том, как я получаю данные. Прямо сейчас я использую избыточность для хранения всех своих данных, извлеченных из базы данных, сохраняя все мои вызовы API в различных действиях. Однако выборка данных становится действительно проблематичной, когда дело доходит до извлечения данных из базы данных, которые затем должны редактироваться пользователем. Чтобы сделать извлекаемые данные редактируемыми, они должны храниться в локальном состоянии компонентов, поэтому хранение данных как в избыточном, так и в локальном состоянии кажется очень неудобным.

Я искал в Интернете конкретные c рекомендации, но я не стал мудрее. Честно говоря, я не думаю, что понял, как правильно использовать редукс. Буду очень признателен за советы по этому вопросу.

Answer 1

В основном используется для управления состоянием приложения . Вы должны рассмотреть свой вариант использования и сами простые вопросы, например

• Вам нужно это состояние для остальных приложений?
• Будут ли другие компоненты затронуты этими состояниями?
• Как часто ваши данные будут меняться?
• Есть ли другие пользователи, использующие те же данные и могут обновлять их?
• Вам нужно кэшировать данные, чтобы предотвратить повторное получение?

Представление, построенное поверх него, отражает это состояние, но не должно использовать этот контейнер состояния исключительно для всего, что оно делает.

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

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

Примечание: Могут быть и другие возможности, которые можно рассмотреть, но это это некоторая базовая c информация, которая, как я думал, будет вам полезна для принятия решения