Why do we need middleware for async flow in Redux

Question

According to the docs   Without middleware  Redux store only supports synchronous data flow   I don t understand why this is the case  Why can t the container component call the async API  and then dispatch the actions    For example  imagine a simple UI  a field and a button  When user pushes the button  the field gets populated with data from a remote server     import   as React from  react   import   as Redux from  redux   import   Provider  connect   from  react-redux    const ActionTypes         STARTED UPDATING   STARTED UPDATING       UPDATED   UPDATED      class AsyncApi       static getFieldValue             const promise   new Promise  resolve    gt                setTimeout      gt                    resolve Math floor Math random     100                   1000                       return promise           class App extends React Component       render             return                lt div gt                   lt input value  this props field   gt                   lt button disabled  this props isWaiting  onClick  this props update  gt Fetch lt  button gt                   this props isWaiting  amp  amp   lt div gt Waiting    lt  div gt                lt  div gt                     App propTypes         dispatch  React PropTypes func      field  React PropTypes any      isWaiting  React PropTypes bool     const reducer    state     field   No data   isWaiting  false    action    gt        switch  action type            case ActionTypes STARTED UPDATING              return      state  isWaiting  true            case ActionTypes UPDATED              return      state  isWaiting  false  field  action payload            default              return state           const store   Redux createStore reducer   const ConnectedApp   connect       state    gt            return      state                dispatch    gt            return               update       gt                    dispatch                       type  ActionTypes STARTED UPDATING                                     AsyncApi getFieldValue                        then result   gt  dispatch                           type  ActionTypes UPDATED                          payload  result                                                          App   export default class extends React Component       render             return  lt Provider store  store  gt  lt ConnectedApp  gt  lt  Provider gt             When the exported component is rendered  I can click the button and the input is updated correctly    Note the update function in the connect call  It dispatches an action that tells the App that it is updating  and then performs an async call  After the call finishes  the provided value is dispatched as a payload of another action   What is wrong with this approach  Why would I want to use Redux Thunk or Redux Promise  as the documentation suggests   EDIT  I searched the Redux repo for clues  and found that Action Creators were required to be pure functions in the past  For example  here s a user trying to provide a better explanation for async data flow      The action creator itself is still a pure function  but the thunk function it returns doesn t need to be  and it can do our async calls   Action creators are no longer required to be pure  So  thunk promise middleware was definitely required in the past  but it seems that this is no longer the case

User · Answer

Abramov s goal - and everyone s ideally - is simply to encapsulate complexity  and async calls  in the place where it s most appropriate    Where s the best place to do that in the standard Redux dataflow  How about    Reducers  No way  They should be pure functions with no side-effects  Updating the store is serious  complicated business  Don t contaminate it  Dumb View Components  Definitely No  They have one concern  presentation and user-interaction  and should be as simple as possible  Container Components  Possible  but sub-optimal  It makes sense in that the container is a place where we encapsulate some view related complexity and interact with the store  but    Containers do need to be more complex than dumb components  but it s still a single responsibility  providing bindings between view and state store  Your async logic is a whole separate concern from that  By placing it in a container  you d be locking your async logic into a single context  for a single view route  Bad idea  Ideally it s all reusable  and totally decoupled    Some other Service Module  Bad idea  you d need to inject access to the store  which is a maintainability testability nightmare  Better to go with the grain of Redux and access the store only using the APIs models provided  Actions and the Middlewares that interpret them  Why not   For starters  it s the only major option we have left   -  More logically  the action system is  decoupled execution logic that you can use from anywhere  It s got access to the store and can dispatch more actions  It has a single responsibility which is to organize the flow of control and data around the application  and most async fits right into that    What about the Action Creators  Why not just do async in there  instead of in the actions themselves  and in Middleware    First and most important  the creators don t have access to the store  as middleware does  That means you can t dispatch new contingent actions  can t read from the store to compose your async  etc   So  keep complexity in a place that s complex of necessity  and keep everything else simple  The creators can then be simple  relatively pure functions that are easy to test

User · Answer

To use Redux-saga is the best middleware in React-redux implementation   Ex       store js    import createSagaMiddleware from  redux-saga     import   createStore  applyMiddleware   from  redux     import allReducer from     reducer allReducer     import rootSaga from     saga      const sagaMiddleware   createSagaMiddleware      const store   createStore       allReducer       applyMiddleware sagaMiddleware           sagaMiddleware run rootSaga     export default store    And then saga js  import  takeLatest delay  from  redux-saga   import  call  put  take  select  from  redux-saga effects   import   push   from  react-router-redux   import data from    data json    export function  updateLesson       try         yield put  type  INITIAL DATA  payload data      initial data from json        yield  takeLatest  UPDATE DETAIL  updateDetail     listen to your action js          catch e         console log  error  e              export function  updateDetail action      try           To write store update details            catch e          console log  error  e             export default function  rootSaga        yield           updateLesson                    And then action js   export default function updateFruit props fruit        return                     type  UPDATE DETAIL            payload fruit           props props                       And then reducer js  import  combineReducers  from  redux    const fetchInitialData    state    action    gt        switch action type         case  INITIAL DATA             return   type action type  payload action payload              break               return state       const updateDetailsData    state    action    gt        switch action type         case  INITIAL DATA             return   type action type  payload action payload              break               return state      const allReducers  combineReducers      data fetchInitialData     updateDetailsData     export default allReducers     And then main js  import React from  react   import ReactDOM from  react-dom   import App from    app components App jsx   import  Provider  from  react-redux   import store from    app store   import createRoutes from    app routes    const initialState       const store   configureStore initialState  browserHistory    ReactDOM render          lt Provider store  store  gt             lt App   gt     is your Component           lt  Provider gt    document getElementById  app       try this   is working

User · Answer

To answer the question that is asked in the beginning      Why can t the container component call the async API  and then dispatch the actions    Keep in mind that those docs are for Redux  not Redux plus React  Redux stores hooked up to React components can do exactly what you say  but a Plain Jane Redux store with no middleware doesn t accept arguments to dispatch except plain ol  objects   Without middleware you could of course still do  const store   createStore reducer   MyAPI doThing   then resp   gt  store dispatch          But it s a similar case where the asynchrony is wrapped around Redux rather than handled by Redux  So  middleware allows for asynchrony by modifying what can be passed directly to dispatch     That said  the spirit of your suggestion is  I think  valid  There are certainly other ways you could handle asynchrony in a Redux   React application   One benefit of using middleware is that you can continue to use action creators as normal without worrying about exactly how they re hooked up  For example  using redux-thunk  the code you wrote would look a lot like  function updateThing       return dispatch   gt        dispatch         type  ActionTypes STARTED UPDATING             AsyncApi getFieldValue          then result   gt  dispatch           type  ActionTypes UPDATED          payload  result                   const ConnectedApp   connect     state    gt       state        update  updateThing     App     which doesn t look all that different from the original     it s just shuffled a bit     and connect doesn t know that updateThing is  or needs to be  asynchronous   If you also wanted to support promises  observables  sagas  or crazy custom and highly declarative action creators  then Redux can do it just by changing what you pass to dispatch  aka  what you return from action creators   No mucking with the React components  or connect calls  necessary

User · Answer

Redux can t return a function instead of an action  It s just a fact  That s why people use Thunk  Read these 14 lines of code to see how it allows the async cycle to work with some added function layering  function createThunkMiddleware extraArgument      return    dispatch  getState      gt   next    gt   action    gt        if  typeof action      function           return action dispatch  getState  extraArgument              return next action           const thunk   createThunkMiddleware    thunk withExtraArgument   createThunkMiddleware   export default thunk   https   github com reduxjs redux-thunk

User · Answer

The short answer  seems like a totally reasonable approach to the asynchrony problem to me  With a couple caveats   I had a very similar line of thought when working on a new project we just started at my job  I was a big fan of vanilla Redux s elegant system for updating the store and rerendering components in a way that stays out of the guts of a React component tree  It seemed weird to me to hook into that elegant dispatch mechanism to handle asynchrony   I ended up going with a really similar approach to what you have there in a library I factored out of our project  which we called react-redux-controller   I ended up not going with the exact approach you have above for a couple reasons    The way you have it written  those dispatching functions don t have access to the store  You can somewhat get around that by having your UI components pass in all of the info the dispatching function needs  But I d argue that this couples those UI components to the dispatching logic unnecessarily  And more problematically  there s no obvious way for the dispatching function to access updated state in async continuations  The dispatching functions have access to dispatch itself via lexical scope  This limits the options for refactoring once that connect statement gets out of hand -- and it s looking pretty unwieldy with just that one update method  So you need some system for letting you compose those dispatcher functions if you break them up into separate modules    Take together  you have to rig up some system to allow dispatch and the store to be injected into your dispatching functions  along with the parameters of the event  I know of three reasonable approaches to this dependency injection    redux-thunk does this in a functional way  by passing them into your thunks  making them not exactly thunks at all  by dome definitions   I haven t worked with the other dispatch middleware approaches  but I assume they re basically the same  react-redux-controller does this with a coroutine  As a bonus  it also gives you access to the  selectors   which are the functions you may have passed in as the first argument to connect  rather than having to work directly with the raw  normalized store  You could also do it the object-oriented way by injecting them into the this context  through a variety of possible mechanisms    Update  It occurs to me that part of this conundrum is a limitation of react-redux  The first argument to connect gets a state snapshot  but not dispatch  The second argument gets dispatch but not the state  Neither argument gets a thunk that closes over the current state  for being able to see updated state at the time of a continuation callback

User · Answer

When working in an enterprise project  there are many requirements available in middle-ware such as  saga  not available in simple asynchronous flow  below are some    Running request in parallel  Pulling future actions without the need to wait  Non-blocking calls Race effect  example pickup first response to initiate the process Sequencing your tasks  first in first call   Composing  Task cancellation Dynamically forking the task  Support Concurrency Running Saga outside the redux middleware   Using channels   The list is long just review the advanced section in saga documentation

User · Answer

What is wrong with this approach  Why would I want to use Redux Thunk or Redux Promise  as the documentation suggests    There is nothing wrong with this approach  It   s just inconvenient in a large application because you   ll have different components performing the same actions  you might want to debounce some actions  or keep some local state like auto-incrementing IDs close to action creators  etc  So it is just easier from the maintenance point of view to extract action creators into separate functions   You can read my answer to    How to dispatch a Redux action with a timeout    for a more detailed walkthrough   Middleware like Redux Thunk or Redux Promise just gives you    syntax sugar    for dispatching thunks or promises  but you don   t have to use it   So  without any middleware  your action creator might look like     action creator function loadData dispatch  userId       needs to dispatch  so it is first argument   return fetch  http   data com   userId         then res   gt  res json         then        data   gt  dispatch   type   LOAD DATA SUCCESS   data           err   gt  dispatch   type   LOAD DATA FAILURE   err                 component componentWillMount       loadData this props dispatch  this props userId      don t forget to pass dispatch     But with Thunk Middleware you can write it like this      action creator function loadData userId      return dispatch   gt  fetch  http   data com   userId       Redux Thunk handles these      then res   gt  res json         then        data   gt  dispatch   type   LOAD DATA SUCCESS   data           err   gt  dispatch   type   LOAD DATA FAILURE   err                 component componentWillMount       this props dispatch loadData this props userId       dispatch like you usually do     So there is no huge difference  One thing I like about the latter approach is that the component doesn   t care that the action creator is async  It just calls dispatch normally  it can also use mapDispatchToProps to bind such action creator with a short syntax  etc  The components don   t know how action creators are implemented  and you can switch between different async approaches  Redux Thunk  Redux Promise  Redux Saga  without changing the components  On the other hand  with the former  explicit approach  your components know exactly that a specific call is async  and needs dispatch to be passed by some convention  for example  as a sync parameter    Also think about how this code will change  Say we want to have a second data loading function  and to combine them in a single action creator   With the first approach we need to be mindful of what kind of action creator we are calling      action creators function loadSomeData dispatch  userId      return fetch  http   data com   userId         then res   gt  res json         then        data   gt  dispatch   type   LOAD SOME DATA SUCCESS   data           err   gt  dispatch   type   LOAD SOME DATA FAILURE   err             function loadOtherData dispatch  userId      return fetch  http   data com   userId         then res   gt  res json         then        data   gt  dispatch   type   LOAD OTHER DATA SUCCESS   data           err   gt  dispatch   type   LOAD OTHER DATA FAILURE   err             function loadAllData dispatch  userId      return Promise all      loadSomeData dispatch  userId      pass dispatch first  it s async     loadOtherData dispatch  userId     pass dispatch first  it s async             component componentWillMount       loadAllData this props dispatch  this props userId      pass dispatch first     With Redux Thunk action creators can dispatch the result of other action creators and not even think whether those are synchronous or asynchronous      action creators function loadSomeData userId      return dispatch   gt  fetch  http   data com   userId         then res   gt  res json         then        data   gt  dispatch   type   LOAD SOME DATA SUCCESS   data           err   gt  dispatch   type   LOAD SOME DATA FAILURE   err             function loadOtherData userId      return dispatch   gt  fetch  http   data com   userId         then res   gt  res json         then        data   gt  dispatch   type   LOAD OTHER DATA SUCCESS   data           err   gt  dispatch   type   LOAD OTHER DATA FAILURE   err             function loadAllData userId      return dispatch   gt  Promise all      dispatch loadSomeData userId       just dispatch normally      dispatch loadOtherData userId      just dispatch normally              component componentWillMount       this props dispatch loadAllData this props userId       just dispatch normally      With this approach  if you later want your action creators to look into current Redux state  you can just use the second getState argument passed to the thunks without modifying the calling code at all   function loadSomeData userId         Thanks to Redux Thunk I can use getState   here without changing callers   return  dispatch  getState    gt        if  getState   data userId  isLoaded          return Promise resolve               fetch  http   data com   userId           then res   gt  res json           then          data   gt  dispatch   type   LOAD SOME DATA SUCCESS   data             err   gt  dispatch   type   LOAD SOME DATA FAILURE   err                     If you need to change it to be synchronous  you can also do this without changing any calling code      I can change it to be a regular action creator without touching callers function loadSomeData userId      return       type   LOAD SOME DATA SUCCESS       data  localStorage getItem  my-data           So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren   t aware of how action creators are implemented  and whether they care about Redux state  whether they are synchronous or asynchronous  and whether or not they call other action creators  The downside is a little bit of indirection  but we believe it   s worth it in real applications   Finally  Redux Thunk and friends is just one possible approach to asynchronous requests in Redux apps  Another interesting approach is Redux Saga which lets you define long-running daemons     sagas     that take actions as they come  and transform or perform requests before outputting actions  This moves the logic from action creators into sagas  You might want to check it out  and later pick what suits you the most      I searched the Redux repo for clues  and found that Action Creators were required to be pure functions in the past     This is incorrect  The docs said this  but the docs were wrong  Action creators were never required to be pure functions  We fixed the docs to reflect that

User · Answer

There are synchronous action creators and then there are asynchronous action creators   A synchronous action creator is one that when we call it  it immediately returns an Action object with all the relevant data attached to that object and its ready to be processed by our reducers   Asynchronous action creators is one in which it will require a little bit of time before it is ready to eventually dispatch an action   By definition  anytime you have an action creator that makes a network request  it is always going to qualify as an async action creator   If you want to have asynchronous action creators inside of a Redux application you have to install something called a middleware that is going to allow you to deal with those asynchronous action creators   You can verify this in the error message that tells us use custom middleware for async actions   So what is a middleware and why do we need it for async flow in Redux   In the context of redux middleware such as redux-thunk  a middleware helps us deal with asynchronous action creators as that is something that Redux cannot handle out of the box   With a middleware integrated into the Redux cycle  we are still calling action creators  that is going to return an action that will be dispatched but now when we dispatch an action  rather than sending it directly off to all of our reducers  we are going to say that an action will be sent through all the different middleware inside the application   Inside of a single Redux app  we can have as many or as few middleware as we want  For the most part  in the projects we work on we will have one or two middleware hooked up to our Redux store   A middleware is a plain JavaScript function that will be called with every single action that we dispatch  Inside of that function a middleware has the opportunity to stop an action from being dispatched to any of the reducers  it can modify an action or just mess around with an action in any way you which for example  we could create a middleware that console logs every action you dispatch just for your viewing pleasure   There are a tremendous number of open source middleware you can install as dependencies into your project   You are not limited to only making use of open source middleware or installing them as dependencies  You can write your own custom middleware and use it inside of your Redux store   One of the more popular uses of middleware  and getting to your answer  is for dealing with asynchronous action creators  probably the most popular middleware out there is redux-thunk and it is about helping you deal with asynchronous action creators   There are many other types of middleware that also help you in dealing with asynchronous action creators

User · Answer

You don t   But    you should use redux-saga     Dan Abramov s answer is right about redux-thunk but I will talk a bit more about redux-saga that is quite similar but more powerful   Imperative VS declarative   DOM  jQuery is imperative   React is declarative Monads  IO is imperative   Free is declarative Redux effects  redux-thunk is imperative   redux-saga is declarative   When you have a thunk in your hands  like an IO monad or a promise  you can t easily know what it will do once you execute  The only way to test a thunk is to execute it  and mock the dispatcher  or the whole outside world if it interacts with more stuff       If you are using mocks  then you are not doing functional programming       Seen through the lens of side-effects  mocks are a flag that your code is impure  and in the functional programmer s eye  proof that something is wrong  Instead of downloading a library to help us check the iceberg is intact  we should be sailing around it    A hardcore TDD Java guy once asked me how you do mocking in Clojure  The answer is  we usually don t  We usually see it as a sign we need to refactor our code    Source  The sagas  as they got implemented in redux-saga  are declarative and like the Free monad or React components  they are much easier to test without any mock   See also this article      in modern FP  we shouldn   t write programs     we should write descriptions of programs  which we can then introspect  transform  and interpret at will     Actually  Redux-saga is like a hybrid  the flow is imperative but the effects are declarative   Confusion  actions events commands     There is a lot of confusion in the frontend world on how some backend concepts like CQRS   EventSourcing and Flux   Redux may be related  mostly because in Flux we use the term  action  which can sometimes represent both imperative code  LOAD USER  and events  USER LOADED   I believe that like event-sourcing  you should only dispatch events   Using sagas in practice  Imagine an app with a link to a user profile  The idiomatic way to handle this with each middleware would be   redux-thunk   lt div onClick  e   gt  dispatch actions loadUserProfile 123   gt Robert lt  div gt   function loadUserProfile userId      return dispatch   gt  fetch  http   data com   userId         then res   gt  res json         then        data   gt  dispatch   type   USER PROFILE LOADED   data           err   gt  dispatch   type   USER PROFILE LOAD FAILED   err               redux-saga   lt div onClick  e   gt  dispatch   type   USER NAME CLICKED   payload  123     gt Robert lt  div gt    function  loadUserProfileOnNameClick       yield  takeLatest  USER NAME CLICKED   fetchUser      function  fetchUser action      try       const userProfile   yield fetch  http   data com   action payload userId         yield put   type   USER PROFILE LOADED   userProfile           catch err        yield put   type   USER PROFILE LOAD FAILED   err            This saga translates to      every time a username gets clicked  fetch the user profile and then dispatch an event with the loaded profile     As you can see  there are some advantages of redux-saga   The usage of takeLatest permits to express that you are only interested to get the data of the last username clicked  handle concurrency problems in case the user click very fast on a lot of usernames   This kind of stuff is hard with thunks  You could have used takeEvery if you don t want this behavior   You keep action creators pure  Note it s still useful to keep actionCreators  in sagas put and components dispatch   as it might help you to add action validation  assertions flow typescript  in the future   Your code becomes much more testable as the effects are declarative  You don t need anymore to trigger rpc-like calls like actions loadUser    Your UI just needs to dispatch what HAS HAPPENED  We only fire events  always in the past tense   and not actions anymore  This means that you can create decoupled  ducks  or Bounded Contexts and that the saga can act as the coupling point between these modular components   This means that your views are more easy to manage because they don t need anymore to contain that translation layer between what has happened and what should happen as an effect   For example imagine an infinite scroll view  CONTAINER SCROLLED can lead to NEXT PAGE LOADED  but is it really the responsibility of the scrollable container to decide whether or not we should load another page  Then he has to be aware of more complicated stuff like whether or not the last page was loaded successfully or if there is already a page that tries to load  or if there is no more items left to load  I don t think so  for maximum reusability the scrollable container should just describe that it has been scrolled  The loading of a page is a  business effect  of that scroll  Some might argue that generators can inherently hide state outside of redux store with local variables  but if you start to orchestrate complex things inside thunks by starting timers etc you would have the same problem anyway  And there s a select effect that now permits to get some state from your Redux store   Sagas can be time-traveled and also enables complex flow logging and dev-tools that are currently being worked on  Here is some simple async flow logging that is already implemented     Decoupling  Sagas are not only replacing redux thunks  They come from backend   distributed systems   event-sourcing   It is a very common misconception that sagas are just here to replace your redux thunks with better testability  Actually this is just an implementation detail of redux-saga  Using declarative effects is better than thunks for testability  but the saga pattern can be implemented on top of imperative or declarative code   In the first place  the saga  is a piece of software that permits to coordinate long running transactions  eventual consistency   and transactions across different bounded contexts  domain driven design jargon    To simplify this for frontend world  imagine there is widget1 and widget2  When some button on widget1 is clicked  then it should have an effect on widget2  Instead of coupling the 2 widgets together  ie widget1 dispatch an action that targets widget2   widget1 only dispatch that its button was clicked  Then the saga listen for this button click and then update widget2 by dispaching a new event that widget2 is aware of   This adds a level of indirection that is unnecessary for simple apps  but make it more easy to scale complex applications  You can now publish widget1 and widget2 to different npm repositories so that they never have to know about each others  without having them to share a global registry of actions  The 2 widgets are now bounded contexts that can live separately  They do not need each others to be consistent and can be reused in other apps as well  The saga is the coupling point between the two widgets that coordinate them in a meaningful way for your business   Some nice articles on how to structure your Redux app  on which you can use Redux-saga for decoupling reasons    http   jaysoo ca 2016 02 28 organizing-redux-application  http   marmelab com blog 2015 12 17 react-directory-structure html https   github com slorber scalable-frontend-with-elm-or-redux   A concrete usecase  notification system  I want my components to be able to trigger the display of in-app notifications  But I don t want my components to be highly coupled to the notification system that has its own business rules  max 3 notifications displayed at the same time   notification queueing  4 seconds display-time etc       I don t want my JSX components to decide when a notification will show hide  I just give it the ability to request a notification  and leave the complex rules inside the saga  This kind of stuff is quite hard to implement with thunks or promises     I ve described here how this can be done with saga  Why is it called a Saga   The term saga comes from the backend world  I initially introduced Yassine  the author of Redux-saga  to that term in a long discussion   Initially  that term was introduced with a paper  the saga pattern was supposed to be used to handle eventual consistency in distributed transactions  but its usage has been extended to a broader definition by backend developers so that it now also covers the  process manager  pattern  somehow the original saga pattern is a specialized form of process manager    Today  the term  saga  is confusing as it can describe 2 different things  As it is used in redux-saga  it does not describe a way to handle distributed transactions but rather a way to coordinate actions in your app  redux-saga could also have been called redux-process-manager    See also    Interview of Yassine about Redux-saga history Kella Byte  Claryfing the Saga pattern Microsoft CQRS Journey  A Saga on Sagas Medium response of Yassine   Alternatives  If you don t like the idea of using generators but you are interested by the saga pattern and its decoupling properties  you can also achieve the same with redux-observable which uses the name epic to describe the exact same pattern  but with RxJS  If you re already familiar with Rx  you ll feel right at home   const loadUserProfileOnNameClickEpic   action    gt    action  ofType  USER NAME CLICKED        switchMap action   gt        Observable ajax  http   data com   action payload userId             map userProfile   gt               type   USER PROFILE LOADED             userProfile                      catch err   gt  Observable of             type   USER PROFILE LOAD FAILED             err                      Some redux-saga useful resources   Redux-saga vs Redux-thunk with async await Managing processes in Redux Saga From actionsCreators to Sagas Snake game implemented with Redux-saga   2017 advises   Don t overuse Redux-saga just for the sake of using it  Testable API calls only are not worth it  Don t remove thunks from your project for most simple cases  Don t hesitate to dispatch thunks in yield put someActionThunk  if it makes sense    If you are frightened of using Redux-saga  or Redux-observable  but just need the decoupling pattern  check redux-dispatch-subscribe  it permits to listen to dispatches and trigger new dispatches in listener   const unsubscribe   store addDispatchListener action   gt      if  action type      ping         store dispatch   type   pong

User · Answer

To Answer the question      Why can t the container component call the async API  and then   dispatch the actions    I would say for at least two reasons   The first reason is the separation of concerns  it s not the job of the action creator to call the api and get data back  you have to have to pass two argument to your action creator function  the action type and a payload   The second reason is because the redux store is waiting for a plain object with mandatory action type and optionally a payload  but here you have to pass the payload too    The action creator should be a plain object like below   function addTodo text      return       type  ADD TODO      text         And the job of Redux-Thunk midleware to dispache the result of your api call to the appropriate action

User · Answer

OK  let s start to see how middleware working first  that quite answer the question  this is the source code applyMiddleWare function in Redux   function applyMiddleware       for  var  len   arguments length  middlewares   Array  len    key   0   key  lt   len   key          middlewares  key    arguments  key          return function  createStore        return function  reducer  preloadedState  enhancer          var store   createStore reducer  preloadedState  enhancer         var  dispatch   store dispatch        var chain              var middlewareAPI             getState  store getState          dispatch  function dispatch action              return  dispatch action                            chain   middlewares map function  middleware            return middleware middlewareAPI                    dispatch   compose apply undefined  chain  store dispatch          return  extends     store            dispatch   dispatch                           Look at this part  see how our dispatch become a function           getState  store getState    dispatch  function dispatch action      return  dispatch action             Note that each middleware will be given the dispatch and getState functions as named arguments       OK  this is how Redux-thunk as one of the most used middlewares for Redux introduce itself      Redux Thunk middleware allows you to write action creators that return   a function instead of an action  The thunk can be used to delay the   dispatch of an action  or to dispatch only if a certain condition is   met  The inner function receives the store methods dispatch and   getState as parameters    So as you see  it will return a function instead an action  means you can wait and call it anytime you want as it s a function     So what the heck is thunk  That s how it s introduced in Wikipedia      In computer programming  a thunk is a subroutine used to inject an   additional calculation into another subroutine  Thunks are primarily   used to delay a calculation until it is needed  or to insert   operations at the beginning or end of the other subroutine  They have   a variety of other applications to compiler code generation and in   modular programming       The term originated as a jocular derivative of  think        A thunk is a function that wraps an expression to delay its   evaluation      calculation of 1   2 is immediate    x     3  let x   1   2     calculation of 1   2 is delayed    foo can be called later to perform the calculation    foo is a thunk   let foo        gt  1   2    So see how easy the concept is and how it can help you manage your async actions     That s something you can live without it  but remember in programming there are always better  neater and proper ways to do things

[javascript] Why do we need middleware for async flow in Redux?

Examples related to javascript

Examples related to asynchronous

Examples related to reactjs

Examples related to redux

Examples related to redux-thunk