I have been following the widely given advice of learning React development by first mastering component `props`, encapsulating UI state in component level `this.state` 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.

Moving on, I am now trying to incorporate more sophisticated state management using `redux`. But as I wade through the complexity and integrate `redux` 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'.

**1) Action Creators as the nexus of business and UI logic**

I find that much of the logic that was previously implemented in the React lifecycle functions `componentDidUpdate` etc., and in `onTouch/onPress` handlers, is now implemented in *action creators*. This seems to be a positive development as it keeps 'everything in the same place' and allows for unit testing.

**Question**: Is it best practice to concentrate business logic in a web of fairly intricate action creators?

**2) Hollowed out `reducers`**

As a corollary to #1 above, I find that my `reducers` and their corresponding `action` 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:

```
case types.SAVE_ORDER: 
  return Object.assign({}, state, {
    order: action.order,
  });

```

A big part of the reason for this is that `reducers` are supposed to be *pure functions* 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 *action creators*, I find it hard to justify arbitrarily migrating complexity into `reducers` simply for the sake of making them 'look useful'.

**Question**: Is it normal, and acceptable practice to have boilerplate `reducers` that function merely as glorified setters to the redux store state?

**3) `redux-thunk` everywhere**

I've asked separately on SO why `redux-thunk` is even necessary (as opposed to calling standard action creators inside of async callbacks/utility functions). I've been pointed to this [answer](https://stackoverflow.com/a/35415559/1628461) by Dan Abramov which provides a very satisfactory explanation (vis-a-vis scalability, server side rendering and myraid other reasons).

Having accepted the necessity of `redux-thunk`, I find that the majority of my *action creators* need to perform async actions, need access to `getState`, or `dispatch` multiple changes to the state. As a result I've been returning '`thunks`' extensively. 

**Question:** Is it normal for a redux application to rely extensively on `thunk`'ed action creators, and rarely to fire a standard object action directly?

**4) Redux as global `this.state`**

In the final analysis, it seems my app's `redux` store has evolved to effectively resemble a global `this.state`. You could think of it as keeping the entire application state in `this.state` in the outermost container component, but without the inevitable mess that comes with passing the said `state` down through nested layers of `props`, and any changes back up the component tree through a rats-nest of *handler* functions.

**Question:** Is *redux* the correct tool to use for a global state store? Are there alternatives out there that behave more akin to *react*'s built-in `this.state`, 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 `switch` statements that come with adopting *redux*?

**5) One single action type?**
This follow up question is inspired by one of the posted comments. 

**Question**: Could one legitimately (in all seriousness, not just blatantly demonstrating a point) use redux with precisely one action type? 

Example - Action creator:

```
export function someActionCreator(various_params){
  return (dispatch, getState => {
    // ... business logic here ....
    asyncIfThisIfThat().then(val => {
      dispatch({
        // type: 'UPDATE_STATE', // Don't even bother setting a type 
        order: val
      })
    })
  )
}

```

The one universal reducer case:

```
export default function app(state = initialState, action = {}) {
  return Object.assign({}, state, action)
  // Just unconditionally merge into state!
}

```

Seems to me this would provide a globally scoped state object that is automatically mapped to `connect`ed components, and one that benefits from all the advantages of immutable state and interoperable with React `props`. In this scheme, **`dispatch` effectively becomes a global `setState`**.

---

Note - Please don't take this question wrong - this is certainly not criticism of *redux*. 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.

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.