2015-07-14 3 views
-1

Я получаю все мои данные на странице загрузке и JSON выглядит следующим образом:Flux архитектуры вложенная и не одноэлементные магазины

{ 
    users: [ 
    { 
     userId: 1, 
     messages: [ 
     { 
      messageId: 1, 
      lines: [/* array of lines */] 
     }, 
     { 
      messageId: 2, 
      lines: [/* array of lines */] 
     }   
     ], 
    }, 
    { 
     userId: 2, 
     messages: [ 
     { 
      messageId: 3, 
      lines: [/* array of lines */] 
     }, 
     { 
      messageId: 4, 
      lines: [/* array of lines */] 
     }   
     ], 
    }, 
    ] 
} 

В качестве примера моей проблемы, сказать, что я пытаюсь осуществить выбор сообщений особенность. Каждый пользователь может иметь одно сообщение selected за раз. Когда я вызываю создателя действия selectMessage(messageId) и который передается до моего MessagesStore, как узнать, какой пользователь должен выбрать сообщение?

Единственный вариант, я вижу, чтобы передать userId вниз по иерархии представлений, а затем добавить, что создатель действия - обработка действия в UsersStore, а не в MessagesStore. Я думаю о архитектуре неправильно?

+0

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

+0

@AndrewMcLagan Извините, можете ли вы быть более четкими в отношении того, что ищете? Возможно, это должно быть сформулировано по-разному, но вы можете поменять «углы» и «клипы» на любое другое существительное, которое вам бы хотелось, это просто вопрос о вложенных данных в магазинах и поддержание одноэлементного паттерна. дайте мне знать, как я могу сделать это более ясным. –

+0

@AndrewMcLagan не уверен, если это более ясно. Но я пытался сделать его менее эзотерическим, чем «углы» и «клипы», и перефразировал вопрос. Дайте мне знать, если это имеет для вас больше смысла. –

ответ

0

Выбор того, из какого магазина сохранить его, зависит от того, как вы выбираете отношение магазинов к компонентам. Некоторые считают, что каждый компонент должен иметь свой собственный магазин. (Я не). Другие пытаются рассматривать магазины как ресурсы (как в REST). Похоже, это то, чему вы учитесь?

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

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

Смежные вопросы