Редуктор/государственная организация для крупных объектов

Question

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

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

Есть ли какие-либо проблемы, которые могут противоречить передовым методам или эффективности использования одного редуктора, который передает весь объект в состояние?

или должно ли мое сокращение и состояние быть более ориентированным на экран, передавая только свойства объекта, который обрабатывает каждый экран?

Answer 1

Прямой ответ. Это зависит

В зависимости от данных, хранящихся на каждом reducer. (Состояние поддерживается каждым)

Если это сложные данные лучше создать отдельный reducer.

Если состояние каждого экрана - это всего лишь плоский объект JSON, сохраните все их в одном reducer.

В конце combineReducers() сделают их доступными для нас в любом месте, которое мы хотим простым connect() методом redux.

Как правило, мы будем поддерживать reducer для container, где контейнер содержит компоненты, которые гидратируются reducer этого контейнера.

Это не проблема, даже если мы поддерживаем «редуктор» для каждого component.

И еще одна хорошая практика, чтобы держать связанные состояние говорят:

cart => cartReducer, который в свою очередь, принимает все действия на состояние cart как ADD_TO_CART, RESET_CART, CHECKOUT_CART, DELETE_ITEM и т.д.

И в вашем случае, если адрес, контакты, изображения и т. Д. Связаны с одним объектом, лучше поддерживать один reducer.