title: React Redux: More containers v.s. less containers
body: <p>As I get further into implementing redux + react into a fairly complex app which depends on many API requests to load a single page, I'm having trouble deciding whether it's better to have a single container component at the root of the page which handles all async stuff and passes props down to dumb components, v.s. having multiple container components which concern themselves only with the data they need, as well as fetching the data they need. I've gone back and forth  between these two patterns and found that they each have pros/cons:</p>
  
  <p>If I put a single container component at the top:</p>
  
  <ul>
  <li><strong>pro:</strong> All <code>isFetching</code> props and <code>fetchSomeDependency()</code> actions can be handled in one place.</li>
  <li><strong>con:</strong> the downside which is really annoying is that I find myself having to forward props and callbacks through multiple components, and certain components in the middle of the tree end up being tied up to this. </li>
  </ul>
  
  <p>Here's a visual example of the issue that shows the relationships required props-wise:</p>
  
  <pre><code>&lt;MyContainer
    data={this.props.data}
    isFetchingData={this.props.isFetchingData}
    fetchData={this.props.fetchData}
   &gt;
     {!isFetchingData &amp;&amp; 
       &lt;MyModal
          someData={props.data}
          fetchData={props.fetchData}
        &gt;
         &lt;MyModalContent
           someData={props.data}
           fetchData={props.fetchData}
         &gt;
            &lt;SomethingThatDependsOnData someData={props.someData} /&gt;
            &lt;SomeButtonThatFetchesData  onClick={props.fetchData} /&gt;
          &lt;/MyModalContent&gt;
        &lt;/MyModal&gt;
      }
   &lt;/MyContainer&gt;
  </code></pre>
  
  <p>As you can see, <code>&lt;MyModal /&gt;</code> and <code>&lt;MyModalContent /&gt;</code> now need to be concerned with props that have nothing to do with it, seeing as a modal should be able to be re-used and only be concerned with stylistic qualities of a modal. </p>
  
  <p>At first the above seemed great but once I got to 100+ components it all felt very tangled, and I found the complexity of these top-level container components to be too high for my liking, seeing as most of them (in the app I'm working on) depend on responses from 3+ API requests.</p>
  
  <p>Then I decided to try multiple containers:</p>
  
  <ul>
  <li><strong>pro:</strong> Completely removes the need to forward props. It still makes sense to do it in some cases, but it's a lot more flexible.</li>
  <li><strong>pro:</strong> Way easier to refactor. I'm surprised at how I can significantly move around and refactor components without anything breaking, whereas in the other pattern things broke a lot.</li>
  <li><strong>pro:</strong> The complexity of each container component is much less. My <code>mapStateToProps</code> and <code>mapDispatchToProps</code> is more specific to the purpose of the component it's in.</li>
  <li><strong>con:</strong> Any component that depends on async stuff will always need to handle <code>isFetching</code> state in itself. This adds complexity that is not necessary in the pattern where its handled in a single container component.</li>
  </ul>
  
  <p>So the main dilemma is that if I use <strong>one container</strong>, I get this un-necessary complexity in components between the root container and the leaf components. If I use <strong>multiple containers</strong>, I get more complexity in the leaf components, and end up with buttons that need to worry about <code>isFetching</code>  even though a button should not be concerned about that.</p>
  
  <p>I'd like to know if anyone has found a way to avoid both cons, and if so, what is the "rule of thumb" you follow to avoid this?</p>
  
  <p>Thanks!</p>