Рекомендации по редукторному составу

Question

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

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

Итак, это мое начальное состояние для страницы:

const initialState = { 
    isFetching: false, 
    isCreating: false, 
    isDeleting: false, // Delete object from the bottom part 
    formStatus: '', // Displays status of the top part of backend call 
    blockStatus: '', // Status for the bottom part. GroupsList 
    statusType: '', 
    groupsList: [] // Fetch list for the bottom part 
}; 

Кроме того, я должен был бы поддерживать свой род отфильтрованного списка, чтобы разместить его бакэнд от groupsList. Было бы неплохо использовать селекторов здесь?

Кроме того, есть другой вызов, который начинается с нижней части страницы с каждого объекта в списке, который у меня есть внизу, и он извлекает дополнительные списки, которые я бы добавил в каждом объекте в groupsList. Итак, для основной ситуации и с учетом того, что рекомендуется сохранить нормализованное состояние, что было бы хорошей практикой, чтобы разрушить мои редукторы?

Редактировать: Я считаю, что в моей информации отсутствуют некоторые ключевые моменты. Итак, эта часть приложения, она разделена на две части. Поэтому у меня есть этот компонент, который я подключил к магазину с именем GroupsPage. У GroupsPage дополнительно имеется два компонента: GroupsForm и GroupsBlock.

• GroupsForm имеет кучу текстовых полей, чтобы позволить пользователю создавать новой группы и при успешном создании он будет добавлен в массив из списка групп в GroupsBlock. GroupsBlock дополнительно содержит компонент Table, который отображает список групп, который я извлекаю из API при загрузке страницы. Каждая строка в блоке групп имеет два значка. Один для редактирует информацию о группах и другие для удаления группы.

Удаление и все остальное просто. Усложнение - это когда кнопка редактирования запускается. При нажатии кнопки редактирования есть вызов API для извлечения некоторых доступных свойств группы, которые я могу перетащить n через модальный список в список групп, а также опубликовать список обновленных групп на бэкэнд.

Так что мой редуктор состав выглядит следующим образом (ПОДРОБНО):

const initialState = { 
      isCreating: false, 
      isUpdatingContainersGroup: false, 
      isFetchingGroups: false, 
      isFetchingGroupHosts: false, 
      isDeleting: false, 
      didCreate: false, 
      didDelete: false, 
      didUpdateContainersGroup: false, 
      didFetchGroups: false, 
      didFetchGroupHosts: false 
      formStatus: '', 
      blockStatus: '', 
      statusType: '' 
      groupsList: [properties: [{}...{}]], 
      availableProperties: [{}.. {}], 
      newProperties: [{}... {}] // Have to maintain an array for new properties added. To post updated data 
       }; 

Так, лично я считаю, что это все довольно перепуталось, и мне нужно какое-то суб восстановителей и, вероятно, селекторов, а также и должен для его реализации в приложении для обеспечения согласованности.

Важная информация Я следую тому же шаблону во всем приложении. Каждая страница имеет форму и блок. И для каждой страницы у меня есть один подключенный компонент, и каждый другой материал, который внутри него, - это просто SFC.

Answer 1

Хотел бы помочь больше, но я все еще в темноте о некоторых вещах. И так как у меня нет 50 репутации, я не могу прокомментировать :) Можете ли вы сделать историю пользователей приложения? Пройдите меня через то, что он делает, почему это так, и как государство имеет смысл. Какой должен быть селектор? Что постоянно вычисляется? У меня такое чувство, что вам не нужно разлагать свои редукторы с информацией, которую вы дали, но я хочу получить лучшее представление о заявке, прежде чем дать свое мнение о том, что делать/что не делать.

Я отредактирую этот ответ после ответа, и на самом деле ответ ваш вопрос. Благодаря!

EDIT: Благодарим за обновление и добавление информации на ваш вопрос, помогает много.

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

Почему эта сложная деталь? Что с этим сложно? Какая часть вас беспокоит?

С потоком данных вашего приложения, я действительно не вижу необходимости разделять редуктор или использовать что-то вроде Reselect. Какие вещи вы используете, чтобы их можно было запомнить?

Я думаю, что у вас есть ваши компоненты, настроенные разумно, но форма вашего магазина redux кажется немного волосатой для того, что делает приложение в настоящее время. Для всех свойств с префиксом is или did; в чем их польза? Есть ли часть пользовательского интерфейса, которая слушает все это? Если это просто передать информацию пользователю, вы можете более общие действия, как это:

{ type: 'APP_STATUS', info: { type: 'success', details: 'Created group' } } 

Вы можете использовать type свойство на info объекта стиль сообщения, как вы. У меня было намного больше успеха, делая это таким образом, вместо того, чтобы иметь 20 свойств в состоянии, которые описывают каждую мелочь.

EDIT 2

Отчасти да, но у меня есть расчеты, которые потребуют принятий существующих вложенных массивов и выплюнуть некоторые данные после применения некоторых операций. Однако то, что я хочу знать atm, состоит в том, что, поскольку у меня есть списки и добавить еще больше объектов в списки, нужно ли сделать это нормализованным в любой форме или продолжать следовать одному и тому же шаблону и вложить его?

Это в значительной степени зависит от вас. По крайней мере, вы можете, конечно, вложить лучшее, но нет ничего плохого в массиве объектов.

Кроме того, я недавно обновил свой редуктор, чтобы иметь три основных объекта. groupsUi, groupsMessages и groupsStore. И каждый объект - - в основном вспомогательный редуктор. Является ли это хорошим способом сохранить мои редукторы чистым и управляемым или есть ли альтернативный способ управления этим лучше?

Вы имеете в виду, что вы обновили свое состояние, чтобы иметь три основных объекта? Разбивая редукторы, важно знать, какую часть государства нужно знать о какой-либо другой части государства. Если что-то может быть достаточно ограниченным, без необходимости знать о остальной части государства, тогда вы в порядке.

Честно говоря, я считаю, что вы находитесь в «Приходите принимать решения самостоятельно» в своем приложении. Я был здесь несколько месяцев назад, и я всегда чувствовал, что был окончательный ответ на то, что я просил. В прошлую пятницу я прошел через рефактор и прошел три отдельных пакета редукции, включая Reselect. Я реализовал их все и пришел к выводу, что они мне не помогли.

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

Прошу прощения. У меня нет прямого ответа на то, что вы делаете, но я считаю, что вы на правильном пути. Верните код, протестируйте его, повторите его, повторите. Вы преуспеете, если вы постоянно ставите под сомнение, что и почему ваше приложение.