Yes, it's true you can do that. However, it's not what we recommend.
I specifically addressed the reasons why we recommend using middleware in the "Side Effects" section of my "Redux Fundamentals" workshop slides [0] [1].
The Redux FAQ entry on "Why do we need things like middleware for async behavior?" [2] also addresses this. In particular, I recommend reading Dan Abramov's answers on Stack Overflow on this top [3] [4]
As always, it's up to you how you choose to write your code, but there's plenty of good reasons why middleware is our recommended approach.
Yes, I'm familiar with the arguments against it, but my experience using Redux has led me to strongly disagree with them. I don't think the proposed benefits have much value in actual practice, and limiting the use of dispatch to plain objects makes state logic easier to understand in my opinion.
Also, I think my primary issue with redux-thunk isn't that you dispatch a non-object but that the getState argument encourages async operations which are dependent on the current store state, possibly its current state at multiple different points of time. Personally I think that as much as possible async operations should be written to use only parameters as input and dispatch actions as output.
Plus I use TypeScript where things like this getState argument are really annoying for strong typing. You need to import the type of your store or store state in every file that uses a thunk.
I also personally think that the extra ceremony applied to Redux is a contributor to the difficulty new developers have understanding it, because they believe that Redux does more than it actually does.
I understand most of your concerns, and it seems like we'll have to agree to disagree to some extent.
FWIW, I specifically addressed several concerns regarding use of `getState` in my post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [0].
I agree that trying to fully capture the potentially dynamic behavior with static types can be painfully difficult. I don't actually use TS myself, yet, but we've definitely had lots of issues pop up related to this (such as [1] ), and I think I get the general issues involved. Unfortunately, I don't have any real suggestions to offer on this front, both because my TS knowledge is limited to "declare types for function params and object fields", and because I'm not sure there _are_ ways around that.
Having said that, our new Redux Starter Kit package [2] is specifically intended to help simplify a number of common Redux use cases, and I'd encourage anyone using Redux to try it out.
Long-term, we plan to revamp the Redux docs content [3], and I hope to improve a lot of the teaching workflow. I also hope to make RSK the "default" way to use Redux for most people.
I do think we need to agree to disagree. That being said according to the README for the Redux Starter Kit these are listed as problems it wants to solve:
• "Configuring a Redux store is too complicated"
• "I have to add a lot of packages to get Redux to do anything useful"
• "Redux requires too much boilerplate code"
I can't help but point out that all of these concerns can also be solved by not using any extra libraries and just doing what I suggested.
Configuration: createStore()
Lot of packages: Not needed, just pass dispatch around.
Boilerplate code: Pretty much just combineReducers calls.
Sorry, I know you're heavily involved in this ecosystem, I just don't really see the need for any of this. create-react-app is mostly about webpack, isn't it? Redux works fine on its own.
FWIW, I'm a Redux maintainer, and I built this specifically in response to how I've seen people _want_ to use Redux, and the concerns they've raised about using Redux. [0]
Almost everyone uses `redux-thunk` [1]. Adding that to a plain Redux store takes a few steps. Adding middleware _and_ setting up the Redux DevTools Extension adds another couple steps [2] So, RSK's `configureStore()` does that by default [3].
Accidental mutation is the #1 mistake folks make when writing Redux apps [4]. So, `configureStore()` adds a middleware by default that warns about that mistake [5].
Writing immutable update logic can be difficult, and especially painful if the updates are nested [6]. Also, many folks don't want to use switch statements for some reason [7]. So, we ship a `createReducer()` utility that lets you write "mutative" immutable updates, and define the reducers as a lookup table [8].
Many people don't like writing action types and action creators by hand. So, RSK includes a `createSlice` utility that generates those automatically. [9]
None of these are incredibly ground-breaking. There's lots of existing Redux addons that do similar things. But, we're including all these utilities in an "official" package, and recommending that folks use it.
No one's being forced to use RSK. But, I can say that just about everyone who's seen this has said something similar to "this looks awesome, I can't wait to use this!".
Look it's excellent for you that many people want to use your work and think it looks awesome. I am just not one of those people, for reasons developed over years of using Redux professionally.
It seems like you think I am just missing something, and that's why I don't agree with you. You should really be more open to the idea that others might think very differently from you and the people you surround yourself with, even after fully considering your ideas.
I also knew you were a Redux contributor when I first responded. I was wondering how long I could disagree with you before you pulled rank.
I've been down this path with acemarke before, about redux-thunk even. All of his commits on Redux are documentation changes, and he feels the need to spam every React thread on this site with comments that start with "I'm a Redux maintainer". In-fact if you google "Redux maintainer" this guy's posts are the first thing that shows up.
Also, when React 16 came out with the new Context API, acemarke made a terrible blog post called "Is Redux Dead?", which had links to some sort of paid Redux training, and linked it everywhere without disclosing that fact. He regularly links said posts from his blog (which I assume have the same links to paid training) under the guise of helping beginners, and I'm really not sold that they actually accomplish that at all. In-fact quite the opposite.
I specifically addressed the reasons why we recommend using middleware in the "Side Effects" section of my "Redux Fundamentals" workshop slides [0] [1].
The Redux FAQ entry on "Why do we need things like middleware for async behavior?" [2] also addresses this. In particular, I recommend reading Dan Abramov's answers on Stack Overflow on this top [3] [4]
As always, it's up to you how you choose to write your code, but there's plenty of good reasons why middleware is our recommended approach.
[0] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...
[1] https://blog.isquaredsoftware.com/presentations/workshops/re...
[2] https://redux.js.org/faq/actions#how-can-i-represent-side-ef...
[3] http://stackoverflow.com/questions/34570758/why-do-we-need-m...
[4] http://stackoverflow.com/questions/35411423/how-to-dispatch-...