Best practices for redux mapStateToProps?
<p>As far as I can tell, <code>reducers</code> change the state of the tree, <code>mapStateToProps</code> transform the state tree for the UI. However, the boundary is not clear. For instance, consider the example from the "Computing Derived Data" docs (<a href="http://redux.js.org/docs/recipes/ComputingDerivedData.html" rel="nofollow">http://redux.js.org/docs/recipes/ComputingDerivedData.html</a>). See below. </p>

<p>My first instinct is to put the calculation of the visible todos <em>in the reducer</em> (and not <code>mapStateToProps</code>), that is, whenever a todo or the visibility filter changes, update the list of completed or active todos. This has several advantages:</p>

<ol>
<li>No need for <code>Reselect</code> </li>
<li>Having all the logic in one place helps reduce the learning curve (when onboarding) and probably also makes it easier to test (since the integration tests for mapStateToProps are simpler, if non-existent).</li>
</ol>

<p>On the other hand, 2) is subjective. So guidance on <code>mapStateToProps</code> would be helpful. </p>

<pre><code>const getVisibleTodos = (todos, filter) =&gt; {
  switch (filter) {
    case 'SHOW_ALL':
      return todos
    case 'SHOW_COMPLETED':
      return todos.filter(t =&gt; t.completed)
    case 'SHOW_ACTIVE':
      return todos.filter(t =&gt; !t.completed)
  }  
}

const mapStateToProps = (state) =&gt; ({
  todos: getVisibleTodos(state.todos, state.visibilityFilter)
})

const mapDispatchToProps = (dispatch) =&gt; ({
  onTodoClick: (id) =&gt; dispatch(toggleTodo(id))         
})

const VisibleTodoList = connect(
  mapStateToProps,
  mapDispatchToProps
)(TodoList)
</code></pre>

<p>Update in response to @DDS: </p>

<blockquote>
  <p>To update multiple interrelated states based on one action means that these states can become out of sync... This could mean the visibleTodoList acquires items that don't exist in the original.</p>
</blockquote>

<p>If by multiple interrelated states you mean <code>visibilityFilter</code> and <code>todos</code>, then as per the redux docs, one idiomatic solution is to refactor the state tree so that they are one state. There are other approaches mentioned in the docs as well. Certainly, as you allude, you now have the burden of ensuring the code to compute the derived state (visible todos) is always called. Once the code base gets large, a custom combineReducer (another idiomatic solution) that does additional transforms before returning the state makes sense.</p>

<blockquote>
  <p>Note that the code lives in separate files and the execution order of reducers is not guaranteed. Also, reducers don't normally have access to sibling state meaning they cannot derive data from it</p>
</blockquote>

<p>See my comments above.</p>

<blockquote>
  <p>The example above may be contrived but the point is that to make the data stable, it's best to have a single source every component can rely on, and this requires the data to be normalized.</p>
</blockquote>

<p>Yea, it all comes down to normalized vs denormalized state. I'm not yet convinced that normalized state is <em>always</em> the way to go...for the same reason NoSQL databases are <em>sometimes</em> the way to go. </p>

<blockquote>
  <p>Reasoning about more complex state [normalized and denormalized state] becomes difficult very quickly. This is why it is better to not put derived data in state.</p>
</blockquote>

<p>Ah I see your point. Six months from now I may not see that <code>visibleTodos</code> is derived state (and so should be treated as readonly). Unexpected things will result.</p>