Redux: Best async serverside loading technique?

Hey, thanks!

Ideally, the loading should take place in the stores themselves

Redux enforces that Stores are completely synchronous. What you describe should happen in the action creator instead.

I _think_ it may even be possible with the default thunk middleware. Your action creator would look like:

export function doSomethingAsync() {
  return (dispatch) => {
    dispatch({ type: SOMETHING_STARTED });

    return requestSomething().then(
      (result) =>  dispatch({ type: SOMETHING_COMPLETED, result }),
      (error) =>  dispatch({ type: SOMETHING_FAILED, error })
    );
  };
}

and handling the actual (granular) actions in the Store.

It's also possible to write a custom middleware to remove the boilerplate.

Genius! I figured I was overlooking something obvious. I like that separation of _doing_ and _storing_.

I look forward to watching this library grow, although it's pretty doggone complete already. Cheers, @gaearon!

You can also write a custom middleware like this

export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    next({ ...rest, readyState: 'request' );
    return promise.then(
      (result) => next({ ...rest, result, readyState: 'success' }),
      (error) => next({ ...rest, error, readyState: 'failure' })
    );
  };
}

and use it instead of the default one.

This will let you write async action creators like

function doSomethingAsync(userId) {
  return {
    type: SOMETHING,
    promise: requestSomething(userId),
    userId
  };
}

and have them turn into

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, readyState: 'success' }
{ type: SOMETHING, userId: 2, readyState: 'failure' }

Ooh, that's nice as well, and more of what I had in mind when I asked the original question. I can't tell if I like the tradeoff in reducing the number of action constants in exchange for adding ifs to check the readyState inside the store. I think I might prefer having addtional _SUCCESS and _FAILURE versions of each action just to avoid putting an if inside a case.

Thanks, though.

Yeah that's totally up to your taste. You could have a similar version that turns types: { request: ..., success: ..., failure: ... } into actions. This is the point of making it a middleware instead of baking into the library: everybody has their own taste to these things.

// Middleware
export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, types, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    const [REQUEST, SUCCESS, FAILURE] = types;
    next({ ...rest, type: REQUEST });
    return promise.then(
      (result) => next({ ...rest, result, type: SUCCESS }),
      (error) => next({ ...rest, error, type: FAILURE })
    );
  };
}

// Usage
function doSomethingAsync(userId) {
  return {
    types: [SOMETHING_REQUEST, SOMETHING_SUCCESS, SOMETHING_FAILURE],
    promise: requestSomething(userId),
    userId
  };
}

Oh man, I love that solution. So much nicer than having the then() and additional calls to dispatch() like the first solution you proposed. Hooray for middleware!

Let me know how (and whether ;-) it works!
We have not really tested custom middleware much.

You left out a } (that's -1 point 😀), but it worked like a charm! First time.

:+1:

@erikras I'm curios how you implemented waiting for the promises to resolve on the server?

This is just pseudocode, so don't go pasting this anywhere, but I'm using react-router (whose api is changing as fast as redux's) something like this:

app.get('/my-app', (req, res) => {
  Router.run(routes, req.path, (error, initialState) => {
    Promise.all(initialState.components
      .filter(component => component.fetchData) // only components with a static fetchData()
      .map(component => {
        // have each component dispatch load actions that return promises
        return component.fetchData(redux.dispatch);
      })) // Promise.all combines all the promises into one
      .then(() => {
        // now fetchData() has been run on every component in my route, and the
        // promises resolved, so we know the redux state is populated
        res.send(generatePage(redux));
      });
  });
});

Does that clear anything up?

@iest

Quoting your problem in Slack:

I’ve got a route handler with

 static async routerWillRun({dispatch}) {
   return await dispatch(UserActions.fooBar());
 }

where UserActions.fooBar() is:

export function fooBar() {
 return dispatch => {
   doAsync().then(() => dispatch({type: FOO_BAR}));
 };
}

then in the server render I’m yielding:

 yield myHandler.routerWillRun({dispatch: redux.dispatch});

but it doesn’t work.

I think the problem here is you're not actually returning anything from fooBar's nested method.

Either remove the braces:

export function fooBar() {
  return dispatch =>
    doAsync().then(() => dispatch({type: FOO_BAR}));
}

or add an explicit return statement:

export function fooBar() {
  return dispatch => {
    return doAsync().then(() => dispatch({type: FOO_BAR}));
  };
}

Either way, it might be easier to use a custom promise middleware as suggested above.

@erikras Regarding your last comment where you are calling the fetchData method on what you have as initialState.components (in the callback of Router.run), the object you get the component references from only return the route handlers matched. What are your thoughts on reaching components that might not be a matched route handler, i.e a child component, but needs to fetch data?

here's an example of what I'm talking about

import React from 'react';
import Router from 'react-router';
import {Route, RouteHandler, DefaultRoute} from 'react-router';

//imagine Bar needs some data
const Bar = React.createClass({
  render(){
    return(
      <div>bar</div>);
  }
});

const Foo = React.createClass({
  render(){
    return (
      <div>
        foo
        <Bar/>
      </div>);
  }
});


const App = React.createClass({
  render(){
    return (
      <div>
        <RouteHandler />
      </div>
    );
  }
});

const routes = (
  <Route path="/" handler={App} name="App">
    <DefaultRoute handler={Foo} name="Foo"/>
  </Route>
);

Router.run(routes,'/',function(Root,state){
  console.log(state);
});

output:

{ path: '/',
  action: null,
  pathname: '/',
  routes: 
   [ { name: 'App',
       path: '/',
       paramNames: [],
       ignoreScrollBehavior: false,
       isDefault: false,
       isNotFound: false,
       onEnter: undefined,
       onLeave: undefined,
       handler: [Object],
       defaultRoute: [Object],
       childRoutes: [Object] },
     { name: 'Foo',
       path: '/',
       paramNames: [],
       ignoreScrollBehavior: false,
       isDefault: true,
       isNotFound: false,
       onEnter: undefined,
       onLeave: undefined,
       handler: [Object] } ],
  params: {},
  query: {} }

You won't have access to Bar in Routes

@erikras Fantastic! That's exactly the kind of route I want to go down. Thanks for sharing.

@iest I hope that pun was intentional, "go down a route" by iterating through the matching routes. :-)

@mattybow That is true. If you _really_ need a component that is not in your routes to load something, then the only option is to run React.renderToString() once (discarding the result), do all your loading in componentWillMount(), and somehow save the promises as you go. This is what I was doing with my own homegrown routing solution before react-router supported server side rendering. I would suggest that needing non-route components to do loading might be a symptom of a design problem. In most use cases a route knows what data its components will need.

@erikras
do you have any public repo to see a whole example on you solution there?

@transedward I wish I did, but my stuff so far using the method I detailed here is still very immature. Sorry.

+1 on the advanced isomorphic example
I love where this is going!

@transedward Here's a sample project with all the bleeding edge tech I've cobbled together. https://github.com/erikras/react-redux-universal-hot-example/

@erikras This is awesome! Can you please submit PR to add it to this README and React Hot Loader's docs' "starter kits" section?

Thanks! PRs submitted.

@erikras Great - Thank you!

Just a note that—based off some of the ides in this conversation—I made a middleware to handle promises: https://github.com/pburtchaell/redux-promise-middleware.

@pburtchaell There is this library by @acdlite as well. https://github.com/acdlite/redux-promise

Two thoughts on this:

1. Promises that get converted to actions could be passed along with the action and put in the Redux Store.

Then, to know if your page is ready to render, simply check if all promises have completed. Perhaps use a middleware that chains all passing promises together and provides a promise for when there are no pending promises.

1. How about letting selectors call actions for missing data?

Suppose you want to render message 3, then your message container will render <Message id={3}> and the message selector will check if state.msgs[3] exists and if not, dispatch a message loading promise.

So combine the two and the components would autoselect their needed data and you'd know when they are done.

I'm pretty sure about “don’t put anything unserializable into store or actions”. It's one of the invariants that's been working really well for me (and allowed time travel, for example) and there need to be _very_ compelling reasons to consider changing it.

Then, to know if your page is ready to render, simply check if all promises have completed. Perhaps use a middleware that chains all passing promises together and provides a promise for when there are no pending promises.

This actually doesn't require to put promises in the store in the end, and I like this. The difference is that, at the end of the dispatch chain, raw actions don't contain any promises. Those are “collected” by the said middleware instead.

One thing I often do when working with promises is to keep a reference to a promise around so that when other requests for the same thing come in, I simply return that same promise, providing debouncing. I then delete the reference some time after the promise completed, providing configurable caching.

I really have to start using Redux in real apps, because I wonder what to do with those references in Redux. I kind of want to stick them into the store to make the actionCreator stateless (or at least making the state explicit). Passing the promise via an action is a nice way to export it, but then you'd need to get it back afterwards somehow. Hmmm.

I'm really looking forward the answer to the last point of @wmertens .
Avoiding multiple concurrent calls (do nothing if something is pending) is a frequent use-case, not sure what is the best way to answer that (because you can't access the store's state from an actionCreator).

Should the actionCreator user (the component) check everytime in the state if he can or not dispatch the action? You have to do it everytime then.. Maybe you need to introduce your own @connect annotation that wrap this?

because you can't access the store's state from an actionCreator

Why? You can do it just fine if you use thunk middleware.

function doSomething() {
  return { type: 'SOMETHING' };
}

function maybeDoSomething() {
  return function (dispatch, getState) {
    if (getState().isFetching) {
      return;
    }

    dispatch(doSomething());
  };
}

store.dispatch(maybeDoSomething());

that solves it!
I thought for a time (for no reason) that accessing the state in actionCreator was a bad practice^^ since the action creator caller can access the state, I don't see why the actionCreator should not, so yeah cool we can do this :)

Thanks @gaearon

@gaearon , is this technique of using Thunk and distinct actions http://gaearon.github.io/redux/docs/api/applyMiddleware.html preferable to your answer above:

You can also write a custom middleware like this

export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    next({ ...rest, readyState: 'request' );
    return promise.then(
      (result) => next({ ...rest, result, readyState: 'success' }),
      (error) => next({ ...rest, error, readyState: 'failure' })
    );
  };
}

and use it instead of the default one.
This will let you write async action creators like

function doSomethingAsync(userId) {
  return {
    type: SOMETHING,
    promise: requestSomething(userId),
    userId
  };
}

and have them turn into

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, readyState: 'success' }
{ type: SOMETHING, userId: 2, readyState: 'failure' }

Also,

I think for the last part, you meant:

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, result, readyState: 'success' }
{ type: SOMETHING, userId: 2, error, readyState: 'failure' }

I'm guessing it just depends on whether one wants to create separate actions for the success or failure callbacks of the promise, rather than using the auto-generated one.

In your thunk example:

function makeASandwichWithSecretSauce(forPerson) {

  // Invert control!
  // Return a function that accepts `dispatch` so we can dispatch later.
  // Thunk middleware knows how to turn thunk async actions into actions.

  return function (dispatch) {
    return fetchSecretSauce().then(
      sauce => dispatch(makeASandwich(forPerson, sauce)),
      error => dispatch(apologize('The Sandwich Shop', forPerson, error))
    );
  };
}

then it wouldn't necessarily make sense to have a generic error callback for a failure to fetch a secret sauce, as there might be different circumstances for fetching the sauce.

Thus I can see the thunk model a bit more flexible.

Possibly something like logging or maybe even the toggling of a "async in progress busy indicator" are more appropriate examples of middleware?

@justin808

Both are fine. Pick what's less verbose for you and what works better for your project. My suggestion is to start with using thunks, and if you see some pattern repeating, extract it into custom middleware. You can mix them too.

I've created an ActionStore for separete the state of the triggered actions (loading, succeeded, failed) from the other state. But I don't known if this goes against the basis of Redux/Flux. I've posted in stackoverflow about this.

@gabrielgiussi I think https://github.com/acdlite/redux-promise also can achieve what you want without you having to store promises in the state. The state is supposed to be serializable at all times.

@wmertens thanks for the advise. I will take a look to the repo but why my state would not be serializable? Or you say it only for I take note?

@gabrielgiussi I didn't look very closely but it seemed like you were
putting promises or functions in the store. In any case, that project
should also work well I think.

On Mon, Aug 10, 2015, 19:15 gabrielgiussi [email protected] wrote:

@wmertens https://github.com/wmertens thanks for the advise. I will
take a look to the repo but why my state would not be serializable? Or you
say it only for I take note?

—
Reply to this email directly or view it on GitHub
https://github.com/gaearon/redux/issues/99#issuecomment-129531103.

Wout.
(typed on mobile, excuse terseness)

Actually, in the store I put custom Action objects, they are just Immutable.Record with simple attribues (id, state, payload) and an action trigger that creates and returns a Promise, so I'm not putting Promises in the Store. But I'm probably breaking something somewhere else, je. Thanks @wmertens.

@gabrielgiussi

and an action trigger that creates and returns a Promise

Don't put functions or anything else that isn't serializable, into the state.

Sorry. I tried to say

and a function trigger that creates and returns a Promise

What I'm actually putting in the store is an Action object (the name was not the best):

export default class Action extends Immutable.Record({state: 'idle', api: null, type: null, payload: null, id: null}){
load(){
  return this.set('state','loading');
}

succeed(){
  return this.set('state','succeeded');
}

fail(){
  return this.set('state','failed');
}

ended(){
  return this.get('state') != 'loading' && this.get('state') != 'idle';
}

endedWithSuccess(){
  return this.get('state') == 'succeeded';
}

endedWithFailure(){
  return this.get('state') == 'failed';
}

trigger() {
  return (dispatch) => {
    dispatch({type: this.get('type') + '_START', action: this});
    let payload = this.get('payload');
    this.get('api').call({dispatch,payload}).then((result) => {
      dispatch({type: this.get('type') + '_SUCCESS',id: this.get('id'), result: result.result});
    }).catch((result) => {
        dispatch({type: this.get('type') + '_FAIL',id: this.get('id'), result: result.result});
      });
  }
}
}

I've created a library for solving this problem (see #539) it works by having middleware return promises for pending actions, and waiting for all those promises to be resolved.

@gaearon this code you wrote https://github.com/rackt/redux/issues/99#issuecomment-112212639,

Is this something that is included the redux library or is it something I have to create manually? Sorry if this is a newb question, just getting into React / Flux (Redux). Just started this tutorial https://github.com/happypoulp/redux-tutorial

@banderson5144

It's not included. It's just there to give you an idea of what you can do—but you're free to do it differently.
Something similar was published as https://github.com/pburtchaell/redux-promise-middleware.

Thanks for this useful info. I wanted to pick your brains on reseting a store -

• You reset the store state for a new user
• You wait on some async actions to complete before giving the user the store and html
• A previously running async action for another user completes and your store gets polluted

How did you guys solve that/have any ideas how to? Just a new store for each user would work instead?

Are you talking about server rendering? Create a new store on every request. We have a guide for server rendering in the docs.

Thanks I'll do that

After trying to understand…

• https://github.com/ForbesLindesay/redux-wait
• https://github.com/erikras/react-redux-universal-hot-example/

Is this too naive? (no one else seems to do this—i think)

// server.js
app.use(function (req, res) {
    match({…}, function (error, redirectLocation, renderProps) {
        …

        if (renderProps) {
            const store = configureStore();

            const promises = renderProps.components.map(function (component, index) {
                if (typeof component.fetchData !== 'function') {
                    return false;
                }

                return component.fetchData(store.dispatch);
            });

            Promise.all(promises).then(function () {
                res.status(200).send(getMarkup(store, renderProps));
            });
        }
    })
});

// home.js
export class Home extends Component {
    static fetchData() {
        return Promise.all([
            dispatch(asyncAction);
        ]);
    },

    componentDidMount() {
        const { dispatch } = this.props;

        Home.fetchData(dispatch);
    }
}

export default connect()(Home);

// action.js
export function asyncAction() {
    return (dispatch, getState) => {
        dispatch(request);

        return fetch(…)
            .then(response => response.json())
            .then(data => dispatch(requestSuccess(data)))
        ;
    }
}

I was also trying to figure out a solution for @mattybow's question https://github.com/rackt/redux/issues/99#issuecomment-112980776 (nested components managing data fetching), but no such success (wasn't sure on how to collect promises from componentWillMount).

@chemoish I'm also trying to get my head around server-side rendering with react and redux. The example in the documentation does not handle this use case very well. I do not want to specify and couple every API request on the server with my components again. The component only should specify how to get the data needed (which the server then should pick up).

Your solutions looks quite good to accomplish that. Did this work out for you? Thanks

Edit: I'm correct that "componentDidMount" does not get triggered again on the client when it is rendered on the server?

@ms88privat I haven't gotten much feedback on the solution yet, nor have tested its limits.

However, the solution posed above requires each page to know the data for all of its children components. I haven't dug deeper into have nested components worry about data management themselves (due to collecting nested promises).

It seems to be doing what you would expect, so its good enough for me for now.

componentDidMount will get triggered again (See https://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount). You can use this or another lifecycle method that suits your needs.

I get around this by preventing the fetch code from executing if the store is already full (or whatever business logic you see fit).

Examine https://github.com/reactjs/redux/blob/master/examples/async/actions/index.js#L47 for an idea of what I am talking about.

@chemoish

I get around this by preventing the fetch code from executing if the store is already full

Okey, I got that. Thanks.

However, the solution posed above requires each page to know the data for all of its children components.

Maybe I misread your solution, but isn't this a necessary requirement regardless of the server-side rendering? (e.g. it should render the same state, if I refresh on the current route, even if it is a SPA)

It would, but you may want a nested component manage its own data fetching, for whatever reason.

For instance, a component that is repeated on many pages, but each page doesn't have much data fetching needs.

@chemoish I'm not sure if we are on the same page. Let me try to explain what my point of view is.

For example I got three nested components:

• component1 (static dataFetch1)
  
  
  
  • component2 (static dataFetch2)
  
  
  • component3 (static dataFetch3)
  
  

Each of them have there own "componentDidMount" methods, with there own dataFetching declarations (dispatching actions via its static dataFetching method).

If I do not have sever-side rendering and I refresh the current URL, my components will mount and trigger all the actions needed to load all the required data afterwards.

With server-side rendering, your match function and renderProps will extract all three components, so I can access all of the static dataFetching methods, which will then allow me to fetch all the data needed for the initial server-side rendering?

Do you have a reference to your match function from your provided example? Thx.

@ms88privat renderProps.components is an array of router components, it doesn't go deeper than that. @chemoish meant that with his implementation you cannot describe the data fetching needs on deeper components.

@DominicTobias thx, do you have a solution to this problem? Is there a possibility to get all the nested components?

Probably this can help? https://github.com/gaearon/react-side-effect
Used to collect all meta tags from nested elements: https://github.com/nfl/react-helmet

Sorry for bumping this discussion again, but I have recently run into the same problem of prefilling state with async action.

I can see that @erikras moved his boilerplate project to redux-async-connect. I wonder, if somebody found another solution?

@vtambourine I have been looking at https://github.com/markdalgleish/redial which is quite helpful

Yes, I have looked through it. But I didn't get, how to make sure data
fetching hooked will not run second time after reinitialization code to n
client.
On Пт, 18 марта 2016 г. at 22:54, Sean Matheson [email protected]
wrote:

@vtambourine https://github.com/vtambourine I have been looking at
https://github.com/markdalgleish/redial which is quite helpful

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/reactjs/redux/issues/99#issuecomment-198517067

Also curious if anyone has found a stable solution for this challenge. I love @erikras's boilerplate, but as @vtambourine mentioned, it has moved to redux-async-connect which seems like it may not be a stable long-term solution: #81 Is redux-async-connect dead?.

@vtambourine there is a fork thats available at https://github.com/makeomatic/redux-connect and is well-maintained. It has similar API with a few changes to it, check it out if you are interested

for those interested in a redux solution with middleware as mentioned by @gaearon I have an example project which implements this technique and allows the components themselves request the data they need server-side

https://github.com/peter-mouland/react-lego-2016#redux-with-promise-middleware

How to unit test action creator with this approach?