Handling errors and cancellation in thunks

Hey @ctrlplusb, congrats on the library! I love this architecture and it seems like you’ve done a really nice job on the API.

I’ve been trying to build a model that fetches some data. I couldn’t see any examples in the docs on how to handle errors (I had a look at onThunk but it didn’t feel right, especially as it doesn’t prevent exceptions being throw) so I’ve set up something like this:

const model = {
  state: 'pending',
  error: null,
  data: null,
  setState: action(...),
  setError: action(...),
  setData: action(...),
  fetchData: thunk(actions => {
    actions.setStatus('loading');
    try {
      const data = await api.getData();
      actions.setStatus('loaded');
      actions.setData(data);
    } catch(err) {
      actions.setStatus('error');
      actions.setError(err);
    }
  })
}

Pretty similar to what you would do with useState and useEffect.

Where I’m struggling now is how to work that thunk into a component. I’d like to be able to cancel the request if the component unmounts. Here’s a couple of examples where the solution is not obvious to me:

const DataView = () => {
  const { data } = useStoreState(state => state.model);
  const { fetchData } = useStoreActions(actions => actions.model);
  // fetch data on mount
  useEffect(() => {
    // can't pass a cleanup function to useEffect as the return value is wrapped in a promise (useEffect callback has to be syncronous)
    fetchData();
  }, [fetchData]);
  return <pre>{JSON.stringify(data)}</pre>;
}

const DataUpdater = () => {
  const { updateData } = useStoreActions(actions => actions.model);
  return <button onClick={() => updateData(newData)}>Update</button>
};

Am I looking at this in completely the wrong way?! Appreciate your thoughts!

[djgrant]

Thanks for the really detailed reply!

[djgrant]

Ah, static method on the promise! Nice idea. I’ll give that a go.

I did have a think about moving data fetching back into components. I think that makes sense if you’re using a GraphQL library, for example, that handles it’s own state logic. In my particular case I’m just calling REST endpoints so being semi indoctrinated in the mobx-state-tree ethos of building state machines that are separate from UI, I’m going for that!