onResolve use old callback

[charleyw]

Hi there,
Thanks for provider this awesome lib, l like the api very much.

I have a situation that in a list page, there will be 3 api calls:

1. loads all the list items when page loads.
2. batch update selected items status, when success should reload the list items
3. another batch update action.

I use following code to implement above logic

const {data, isLoading, reload} = useAsync({promiseFn: loadAllItems, query: query, watch: "...."})

// query is from url params, there is a filter bar to update this. i use watch update auto reload.

const handleBatchUpdateSuccess = () => {
   mesasge.info("success")
   reload()
}

const {run: batchUpdate} = useAsync({deferFn: batchUpdateItems, onResolve: handleBatchUpdateSuccess})

const {run: anotherBatchUpdate} = useAsync({deferFn: anotherBatchUpdateItems, onResolve: handleBatchUpdateSuccess})

Problems occurs as following:

1. Refresh the page, so all the data reloads, we say it's the filter1
2. Change the filter, so the data reloaded, we say it's the filter2
3. use the batchUpdate action, then page reload again. but the reload is using the filter1 instead of filter2.

I've tried to not use onResolve, but using the onEffect to watch the batchUpdateLoading to fire the same callback(handleBatchUpdateSuccess), and it's act as expected.

So i guess whether there are some machism that cached the onResolve callback.

[Kaltsoon]

Wouldn't it be a lot easier to use some state information (such as a timestamp of the latest update) in watch to refetch the items when required. For example:

const [updatedAt, setUpdatedAt] = useState(null);

const { data: items = [] } = useAsync({ promiseFn: fetchItems, watch: updatedAt });

const onRefetchItems = useCallback(() => {
  setUpdatedAt(Date.now());
});

return (
  <>
    {items.join(',')}
    <button onClick={onRefetchItems}>Refetch</button>
  </>
);

[ghengeveld]

What about this?

const {data: batchData, run: batchUpdate} = useAsync({deferFn: batchUpdateItems})
const {data: anotherBatchData, run: anotherBatchUpdate} = useAsync({deferFn: anotherBatchUpdateItems})
const {data, isLoading, reload} = useAsync({
  promiseFn: loadAllItems, 
  query: query, 
  batchData: batchData,
  anotherBatchData: anotherBatchData,
  watchFn: (props, prevProps) => props.batchData !== prevProps.batchData || props.anotherBatchData !== prevProps.anotherBatchData
})

Alternatively:

const batchUpdateItems = fetch(/* do your thing */)
  .then(loadAllItems) // must return same shape of data

const {data, isLoading, run} = useAsync({
  promiseFn: loadAllItems, 
  deferFn: batchUpdateItems, 
  query: query, 
  watch: query
})

This last approach essentially blends it all together into one Async operation, but requires your updates to return the same data that loadAllItems would. In this case I think that's feasible and maybe even preferable. Using both promiseFn and deferFn together is meant for exactly this use case, where they operate on the same data. The downside is you can't have two deferFns, so you would need to merge those two together. How that works is very specific to your use case and I don't have enough information right now to judge if that makes sense.

[ghengeveld]

Getting back to your original issue (reload not using the most recent props), I have two theories:

Either this is caused by useMemo which is applied to the return value of useAsync. The return value of useAsync will currently only change when its internal state changes (i.e. data / error / startedAt / finishedAt). An update in a different instance of useAsync will not cause such a state change, so you will still have the old version of reload.

Or, this is caused by handleBatchUpdateSuccess closing over the reload value, making it refer to an older version (the one that existed when useAsync is first called).

I will need to have a sandbox example to figure out what exactly is going on. Can you maybe provide one? Just a simple example with 2 useAsyncs, doing exactly what you described?

[charleyw]

@Kaltsoon thanks for reply, but my case is watch the filter query (which is stored in url search), reload with new query when they changed.

@ghengeveld I followed your suggestion to combine the load all item and batch update action to a single useAsync, but there are somthing not good for this one:

1. Added extra code to determine which batchUpdateAction is executing,
2. Added extra code to determine whether is loading item success or batchUpdate success
3. Currently i have only two batch updates, i'm afraid if i have more actions that can not merge into one.

The first two are something that i choose react-async to help me avoid, but now everything goes wrong.

I created a sample to explain my situation. https://codesandbox.io/embed/pp4lv8knkm

1. when page loaded, you can see a log that shows a loadAllItems api call without query
2. You can click update query button, then another loadAllItems api call with query will be fired due to watch
3. You click Batch update button, you can see a batch update api call fired. Then a reload has been fired without query which is expected to use latest query that updated in step two.

[charleyw]

@ghengeveld is there any progress ?

[ghengeveld]

Sorry for the delay. Unfortunately I have been busy with other tasks so I haven't gotten around to dealing with this issue. Right now my focus is on getting v6 released (see #37), which is a major milestone. I expect to release this very soon (maybe even today), after which I can get back to this issue.

[ghengeveld]

I looked at your sandbox and was able to find a workaround for your issue. Instead of using onResolve: reload on your batch update action, you can do this instead:

<button onClick={() => run().then(reload)}>Batch update</button>

Meanwhile I'll fix the underlying issue: run is wrapped with useMemo, which prevents it from updating when onResolve or onReject changes. I'll add those to the useMemo dependencies list.

[ghengeveld]

Released in v6.0.2