Redefine useAsync to separate config async config from parameters to the promiseFn

[MrHus]

This is a proposal for a change in the way useAsync works. I propose to add a third parameter, which is an object which is passed as the first argument to the promiseFn.

Currently this information is passed along in the AsyncOptions as [prop: string]: any:

export interface AsyncOptions<T> {
  promise?: Promise<T>
  promiseFn?: PromiseFn<T>
  // abbreviated
  debugLabel?: string
  [prop: string]: any
}

This makes the arguments to the promiseFn unsafe. Which is not nice for the developer experience. Plus it makes the AsyncOptions have a strange dual role.

My Proposal would create a dedicated parameter for the parameters to the promiseFn function like so :

type LoadDataConfig = {
  id: string
}

export function loadData(config: LoadDataConfig, props: AsyncProps<Link>, controller: AbortController) {
  return Link.one(config.id);
}

export default function AwesomeComponent() {
  const { id } = useParams();
  const state = useAsync(loadLink, { id }, { watch: id });
}

This would also mean redefining PromiseFn like so:

export type PromiseFn<T, C> = (config: C, props: AsyncProps<T>, controller: AbortController) => Promise<T>

Another less breaking options would be to add the config to AsyncOptions:

export interface AsyncOptions<T, C> {
  promise?: Promise<T>
  promiseFn?: PromiseFn<T>
  // abbreviated
  debugLabel?: string
config: C
  [prop: string]: any
}

This would at least make the config type safe, but makes the api a little nicer.

[ghengeveld]

I'd really love to make the additional props type safe, so I like your proposal. Let's try to come up with a solution that solves multiple problems we have right now.

I prefer to avoid introducing any API changes, such as adding an extra argument at the start of the argument list for PromiseFn. However, I'd also like to get rid of the difference in arguments between PromiseFn and DeferFn (which receives one more argument). Maybe this is an opportunity to fix that too.

That would mean DeferFn and PromiseFn both receive 3 arguments, the first being something of type C (let's call it context). For PromiseFn it would be the thing you passed to useAsync and for DeferFn it would be the thing you passed to run.

function(context: C, props: Object, controller: AbortController): Promise<T>

We can't easily add an extra argument to useAsync because it's already overloaded. I mean we could but I prefer not to make it even more complicated. Instead let's just add context on AsyncOptions.

Would you be willing to setup a PR for this?

[MrHus]

I'll try to make a PR.

[samit4me]

This looks like it might also resolve #256

Is there plans to make this happen or is it still just an idea at the moment?

[ghengeveld]

I'm still down for this change. Just swamped at the moment.

[ghengeveld]

There's this PR by the way: #247

Would be great if someone could review it.