developit / unistore

🌶 350b / 650b state container with component actions for Preact & React
https://npm.im/unistore
2.86k stars 139 forks source link

Race in the async action example? #165

Open mindplay-dk opened 5 years ago

mindplay-dk commented 5 years ago

I'm wondering about this example in the README:

  // Async actions can be pure async/promise functions:
  async getStuff(state) {
    let res = await fetch('/foo.json')
    return { stuff: await res.json() }
  },

I don't fully understand how you can really support async actions like in this example.

If getStuff() is called twice before the first call resolves, and the two fetch() operations happen to finish in reverse order (because HTTP servers are unpredictable) doesn't this cause a race condition?

Won't you end up with the stuff from the first request instead of the second?

I understand (from reading this issue) that the internal call to setState() is defferred until the promise resolves - but I don't think that's enough to guarantee that setState() calls are performed in the same order the actions were invoked?

For something like an auto-complete input fetching results from the server-side, it seems like there's a good chance of this actually happening.

Do I have to manually prevent races?

developit commented 5 years ago

This is a footgun, yes. In general, concurrent execution of actions that write to the same state properties is a bad idea, unless a locking mechanism is used:

actions = store => ({
  async getStuff(state) {
    // async actions already typically do an initial store update to indicate pending state.
    // the suggestion is to also write a lock of some kind here:
    const lock = {};
    store.setState({ pending: true, lock });

    const res = await fetch('/foo.json')
    const stuff = await res.json();

    // if someone else overwrote our lock, discard the action's return value.
    if (store.getState().lock !== lock) return;

    return { pending: false, stuff };
  }
})