title: Use of boilerplate actions and reducers in redux
body: <p>I have been following the widely given advice of learning React development by first mastering component <code>props</code>, encapsulating UI state in component level <code>this.state</code> and passing it down selectively through the component tree. It's been an enlightening experience. I've come to appreciate the power of the stateless view design pattern and I feel that I've been able to achieve robust and well organized results using these techniques.</p>
  
  <p>Moving on, I am now trying to incorporate more sophisticated state management using <code>redux</code>. But as I wade through the complexity and integrate <code>redux</code> into my apps,  I find myself confronting the following observations about how my code has evolved. Some of these developments seem sensible, but others make me question whether I'm doing things 'right'.</p>
  
  <p><strong>1) Action Creators as the nexus of business and UI logic</strong></p>
  
  <p>I find that much of the logic that was previously implemented in the React lifecycle functions <code>componentDidUpdate</code> etc., and in <code>onTouch/onPress</code> handlers, is now implemented in <em>action creators</em>. This seems to be a positive development as it keeps 'everything in the same place' and allows for unit testing.</p>
  
  <p><strong>Question</strong>: Is it best practice to concentrate business logic in a web of fairly intricate action creators?</p>
  
  <p><strong>2) Hollowed out <code>reducers</code></strong></p>
  
  <p>As a corollary to #1 above, I find that my <code>reducers</code> and their corresponding <code>action</code> objects have evolved into a de-facto list of setters that do little more than update the state store with the passed along values, in this fashion:</p>
  
  <pre><code>case types.SAVE_ORDER: 
    return Object.assign({}, state, {
      order: action.order,
    });
  </code></pre>
  
  <p>A big part of the reason for this is that <code>reducers</code> are supposed to be <em>pure functions</em> and therefore I'm limited in what I can do with them (e.g. no async processing). Additionally, reducers are allowed only to operate on their respective sub-section of the store state. Given that much of my app's complexity already necessarily resides in the <em>action creators</em>, I find it hard to justify arbitrarily migrating complexity into <code>reducers</code> simply for the sake of making them 'look useful'.</p>
  
  <p><strong>Question</strong>: Is it normal, and acceptable practice to have boilerplate <code>reducers</code> that function merely as glorified setters to the redux store state?</p>
  
  <p><strong>3) <code>redux-thunk</code> everywhere</strong></p>
  
  <p>I've asked separately on SO why <code>redux-thunk</code> is even necessary (as opposed to calling standard action creators inside of async callbacks/utility functions). I've been pointed to this <a href="https://stackoverflow.com/a/35415559/1628461">answer</a> by Dan Abramov which provides a very satisfactory explanation (vis-a-vis scalability, server side rendering and myraid other reasons).</p>
  
  <p>Having accepted the necessity of <code>redux-thunk</code>, I find that the majority of my <em>action creators</em> need to perform async actions, need access to <code>getState</code>, or <code>dispatch</code> multiple changes to the state. As a result I've been returning '<code>thunks</code>' extensively. </p>
  
  <p><strong>Question:</strong> Is it normal for a redux application to rely extensively on <code>thunk</code>'ed action creators, and rarely to fire a standard object action directly?</p>
  
  <p><strong>4) Redux as global <code>this.state</code></strong></p>
  
  <p>In the final analysis, it seems my app's <code>redux</code> store has evolved to effectively resemble a global <code>this.state</code>. You could think of it as keeping the entire application state in <code>this.state</code> in the outermost container component, but without the inevitable mess that comes with passing the said <code>state</code> down through nested layers of <code>props</code>, and any changes back up the component tree through a rats-nest of <em>handler</em> functions.</p>
  
  <p><strong>Question:</strong> Is <em>redux</em> the correct tool to use for a global state store? Are there alternatives out there that behave more akin to <em>react</em>'s built-in <code>this.state</code>, allowing a global application state to be propagated through stateless react components, and updated from throughout the application via a centralized 'switchboard', without the seemingly endless web of boilerplate, constants and <code>switch</code> statements that come with adopting <em>redux</em>?</p>
  
  <p><strong>5) One single action type?</strong>
  This follow up question is inspired by one of the posted comments. </p>
  
  <p><strong>Question</strong>: Could one legitimately (in all seriousness, not just blatantly demonstrating a point) use redux with precisely one action type? </p>
  
  <p>Example - Action creator:</p>
  
  <pre><code>export function someActionCreator(various_params){
    return (dispatch, getState =&gt; {
      // ... business logic here ....
      asyncIfThisIfThat().then(val =&gt; {
        dispatch({
          // type: 'UPDATE_STATE', // Don't even bother setting a type 
          order: val
        })
      })
    )
  }
  </code></pre>
  
  <p>The one universal reducer case:</p>
  
  <pre><code>export default function app(state = initialState, action = {}) {
    return Object.assign({}, state, action)
    // Just unconditionally merge into state!
  }
  </code></pre>
  
  <p>Seems to me this would provide a globally scoped state object that is automatically mapped to <code>connect</code>ed components, and one that benefits from all the advantages of immutable state and interoperable with React <code>props</code>. In this scheme, <strong><code>dispatch</code> effectively becomes a global <code>setState</code></strong>.</p>
  
  <hr>
  
  <p>Note - Please don't take this question wrong - this is certainly not criticism of <em>redux</em>. As a learner I am obviously in no position to judge a technology backed by the expertise of thousands and the support of millions. I have no doubt of its value in the right context.</p>
  
  <p>I'm just sensing the smell of a questionable pattern in my own code and wondering what, if anything I'm doing wrong, or whether I'm using the right tool for the task.</p>