Зачем использовать один магазин на объект в архитектуре приложений Flux?
Я использую реагирование и архитектуру потока в проекте, над которым я работаю. Я немного озадачен тем, как правильно разбить вложенные данные на хранилища и почему я должен разбивать свои данные на несколько хранилищ.
Чтобы объяснить проблему, я буду использовать этот пример:
Представьте себе приложение Todo, где у вас есть проекты. Каждый проект имеет задачи, и каждая задача может иметь заметки.
Приложение использует API REST для извлечения данных, возвращая следующий ответ:
{
projects: [
{
id: 1,
name: "Action Required",
tasks: [
{
id: 1,
name: "Go grocery shopping",
notes: [
{
id: 1,
name: "Check shop 1"
},
{
id: 2,
name: "Also check shop 2"
}
]
}
]
},
]
}
Интерфейс фиктивного приложения отображает список проектов слева, и когда вы выбираете проект, этот проект становится активным, а его задачи отображаются справа. При нажатии на задачу вы можете увидеть ее заметки во всплывающем окне.
Я бы использовал один магазин - «Магазин проектов». Действие выполняет запрос к серверу, извлекает данные и дает указание хранилищу заполнить себя новыми данными. Хранилище внутренне сохраняет это дерево сущностей (Проекты -> Задачи -> Заметки).
Чтобы иметь возможность отображать и скрывать задачи в зависимости от того, какой проект выбран, я бы также оставил в хранилище переменную "activeProjectId". На основании этого представление может получить активный проект, его задачи и отрендерить их.
Задача решена.
Однако: после небольшого поиска в Интернете, чтобы увидеть, является ли это хорошим решением, я вижу, что многие люди заявляют, что вы должны использовать отдельный магазин для каждой сущности.
Это будет означать: ProjectStore, TaskStore и NoteStore. Чтобы иметь возможность управлять ассоциациями, мне также могут понадобиться TasksByProjectStore и NotesByTaskStore.
Может кто-нибудь объяснить, почему это было бы лучше? Единственное, что я вижу, - это большие накладные расходы на управление магазинами и потоком данных.