[✨] support qwik functions(use*) after async callsites(await...)

[revintec]

in version 0.18.1, latest version as of writing, we can't use qwik functions(use*) after await
this limitation is here to because when qwik functions are called, a proper executionContext must be recoverable

but it's an implementation detail and it makes qwik harder to use, requires more boilerplate code(useSignal<...>(...), useTask$(async...), if(!signal.value)return, etc.) when async callsites are involved

I propose a way to solve this, in 2 steps

1. implements const restoreEnv=useCallsite() or const restoreEnv=useAsync() by
   function useCallsite(){const ctxt=tryGetInvokeContext();return()=>void(_context=ctxt);}
   I actually appended export const USE_CONTEXT=()=>{const ctxt=_context;return()=>_context=ctxt} to core.mjs for testing, and currently found no major problems. there're however some edge cases and warnings

then users can use it like this:

  component$(async(...)=>{
    ...
    const restoreEnv=USE_CONTEXT()
    await ...
    restoreEnv()
    ...
    useSignal(...)
    ...
  }

2. in the future, the qwik compiler should be able to detect await callsites, and add restoreEnv(...) automatically
   but this is tricky so we can implement 1 first, which should be easier to implement and reason about

original POST follows

Is your feature request related to a problem?

currently code like export default component$(async()=>...) would compile and work fine
notice the async there. but vscode is reporting syntax error

Argument of type '() => Promise<JSXNode<any> | null>' is not assignable to parameter of type 'OnRenderFn<{}>'.
  Type 'Promise<JSXNode<any> | null>' is missing the following properties from type 'JSXNode<any>': type, props, key
ts(2345)

Describe the solution you'd like

can we modify https://github.com/BuilderIO/qwik/blob/70880b71995361202ae0b4725454cb2bd008ab2d/packages/qwik/src/core/component/component.public.ts to update the component$ signature?

from export type OnRenderFn<PROPS> = (props: PROPS) => JSXNode<any> | null
to export type OnRenderFn<PROPS> = (props: PROPS) => ValueOrPromise<JSXNode<any> | null>

it's a small change but I don't know if it's acceptable/compatible/safe

Describe alternatives you've considered

export default component$(()=><>{(async()=>...)()}</>)

but that's ugly and verbose

Additional context

No response

[DustinJSilk]

You shouldnt be putting async code directly in a component function.
Try place your async tasks in a useTask$ hook instead, and update a store/signal with the new state.

[revintec]

@DustinJSilk that sure is an alternative solution, but it still is more verbose
why not using async code? is it because of the latency to FCP or the inability to display loading status?

[revintec]

BTW accessing signal(useSignal()) value(signal.value) after await seems not working

[shairez]

Hi @revintec !

This is not a simple change
We used to have async for component$ but we removed it

According to @manucorporat , adding async await ability to component functions messes up the execution context.

[manucorporat]

BTW accessing signal(useSignal()) value(signal.value) after await seems not working

right! that's why we dont allow it. this is not a good idea, all this processing should be done inside a useTask!

[revintec]

thanks for the history, I didn't know that
however I've noticed that useTask$(...) do support async functions, and there're already vscode linters telling people that using qwik functions after await may not gonna work, is it possible to allow users continue using async in component$(...) thus simplifying their code, but if they use any qwik functions we use (the already existing) linter to warn them?

below is an example with only one async/await callsite, image 3(which should be common

use case that allows async:

component$(async()=>{
  const somedata=await(await fetch(...)).json()
  return <>{JSON.stringify(somedata)}</>
})

if not, we have to add more boilerplate code, it's like callback hell all over again:

interface UselessDefinition{dataRef:Signal<...>}
const UselessComponentToIsolateReendering=component$<UselessDefinition>(({dataRef})=>{
  return<>{dataRef.value?JSON.stringify(dataRef.value):"loading maybe? but this text won't show up anyways"}</>
})
component$(()=>{
  const uselessIntermediateVariable=useSignal<...>()
  fetch(...).then((uselessName)=>{
    uselessName.json().then((uselessName2)=>{
        uselessIntermediateVariable.value=uselessName2
    }).catch(...)
  }).catch(...)
  if(!uselessIntermediateVariable.value)return; // this line triggers a error, but it works at runtime
  return<UselessComponentToIsolateReendering dataRef={uselessIntermediateVariable}/>
})

maybe a little exacerbated because of the long variable/type name, but you get the point

if we assume useTask$(...) can handle async functions(and continue to support them
we can replace fetch(...).then((...)=>then...) with useTask$(async()=>await...)

[revintec]

about the execution context, I understand why they got messed up, and it seems we can restore them like this

component$(({restoreExecutionContext})=>{
  ...
  await ...
  restoreExecutionContext()
  ...
  qwikFunctionCall...
  return ...
})

but I think that's not very user-friendly, so until a better idea come along, let's leave that to another PR :)

I've edited the original post according to this

[gioboa]

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.

[loganpowell]

I know this has been sitting on a back burner for quite some time. If it is very difficult, it's understandable that you can't support it, but being able to use just a straight async await syntax inside of a component without having to know anything else would be incredible. Perhaps the signal could be a custom mutable object given to the async component as props and connected to the lifecycle? Something like:

export default component$(async ({ signal }) => {
  const text = signal('Initial text');
  text.value = await fetch("https://api.com/json/default-text")

  return (
    <section>
        Enter text: <input bind:value={text} />
    </section>
  );
});

[wmertens]

@loganpowell the correct way to fix this is to convert async functions to generator functions and have them be handled correctly, always providing the context for the next sync call.

This isn't too hard because we have the optimizer that processes all code, but it introduces some magic, which is generally not something we like.

This also means that tasks go from explicitly tracking dependencies to implicitly tracking them, and having to explicitly untrack them. So existing code would start to behave differently, unless we only do this async tracking for some things, which then makes the framework harder to reason about.

So I'm not saying we shouldn't do it, but we have to consider it carefully and it would be something for v3.

[wmertens]

Let's make it so that we accept generator functions everywhere that we normally accept async functions (we can even do it for components), and they get auto tracking.

Having the optimizer automagically transform async/await to generators is a step further and that is a bit against Qwik principles, but maybe we could allow it with a configuration, or just expect the dev to add the transform themselves.

Example: Instead of

useTask$(async ({track}) => {
  const result = await foo
  await doThing(result, track(signal))
})

you could write

useTask$(function*() {
  const result = yield foo
  yield doThing(result, signal.value)
})

, so simply replace async with function* and all await with yield.

The core would detect a generator result (iterator) and receive promises from it, wait for them and then invoke the iterator with the result, maintaining the context needed for reactive tracking.

The only problem is that in order to do this, the tracking needs to already happen on the first call, before we know that we'll get an iterator back.

So that means we'll have a slightly breaking change, that reactive state before the first await is automatically tracked. If that is undesirable, untrack must be used by the dev.

Another options is to make the initial track tentative, but that means non-trivial overhead in the async callback case.