title: Why use one store per entity in the flux application architecture?
body: <p>I am using reactjs and the flux architecture in a project I'm working on. I am a bit puzzled by how to break up nested data correctly into stores and why I should split up my data into multiple stores.</p>
  
  <p>To explain the problem I'll use this example:</p>
  
  <p>Imagine a Todo application where you have Projects. Each project has tasks and each task can have notes.</p>
  
  <p>The application uses a REST api to retrieve the data, returning the following response:</p>
  
  <pre><code>{
      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"
                          }
                      ]
                  }
              ]
          },
      ]
  }
  </code></pre>
  
  <p>The fictive application's interface displays a list of projects on the left and when you select a project, that project becomes active and its tasks are displayed on the right. When you click a task you can see its notes in a popup.</p>
  
  <p>What I would do is use 1 single store, the "Project Store". An action does the request to the server, fetches the data and instructs the store to fill itself with the new data. The store internally saves this tree of entities (Projects -> Tasks -> Notes).</p>
  
  <p>To be able to show and hide tasks based on which project is selected I'd also keep a variable in the store, "activeProjectId". Based on that the view can get the active project, its tasks and render them.</p>
  
  <p>Problem solved.</p>
  
  <p>However: after searching a bit online to see if this is a good solution I see a lot of people stating that you should use a separate store per entity.</p>
  
  <p>This would mean:
  A ProjectStore, TaskStore and NoteStore. To be able to manage associations I would possibly also need a "TasksByProjectStore" and a "NotesByTaskStore".</p>
  
  <p>Can someone please explain why this would be better? The only thing I see is a lot of overhead in managing the stores and the data flow.</p>