This is probably fixed in v2 :D

Although the type fix is probably an easy fix in v1 too no?

Ok I see - but why use an async function here? The render functions are like inline components and those aren't supposed to be async, because it breaks reactivity tracking.

So not sure we should support this @maiieul @Varixo

Hmmm good point. I intuitively went for async inside onResolved to track some analytics data in our codebase. It does work for this use-case but if it breaks reactivity in certain cases then we need to document not to do that and instead create a component$ that can be passed to the onResolved.

@wmertens are you sure that the render functions behave like inline components and that it breask reactivity tracking? Shouldn't we have a test breaking in that case?

It seems to me that doing

        onResolved={async (data) => {
          return <p>Data: {data}</p>;
        }}

is different from

        onResolved={async (data) => {
          return <InlineComponent data={data} />;
        }}

...

const InlineComponent = async ({data}: {data:string}) => {
  return <p>Data: {data}</p>
}

If returning Promise<JSXOutput> doesn't break reactivity I think it's a more intuitive API than constraining the user into creating a component$ just to handle side effects.