Async in onMount OK?

Is the following pattern OK?

export const AppUI: Component = () => {
  onMount(async () => {
    // await ...
  })

  return (
    <div>
       ...
    </div>
  )
}

export const AppUI: Component = () => {
  onMount(async () => {
    // await ...
  })

  return (
    <div>
       ...
    </div>
  )
}

I've always used it, but now Biome added https://biomejs.dev/linter/rules/no-misused-promises/ and it thinks it's an error, because "This function returns a Promise, but no return value was expected. This may not have the desired result if you expect the Promise to be await-ed."

Biome

noMisusedPromises

Learn more about noMisusedPromises

13 Replies

Madaxen86•2mo ago

I think it’s fine . Personally I use createAsync or createResource for any async .

hyperknotOP•2mo ago

I thought onMount was a special one for one-time running only. Now I'm reading that onMount is the same as a createEffect? BTW, I only found createAsync in Solid Router. createResource seems to be in Core. Can you explain the differences between these?

Madaxen86•2mo ago

onMount is one time only /or only once per mount of the component. createAsync is a wrapper around createResource with a simpler api (it auto tracks the functions args) and returns a signal /accessor. with createAsync and query you can also co-locate async data as requests are deduped. createAsync will also be in core in Solid2.0

hyperknotOP•2mo ago

I see. But why would I use it to replace onMount?

Madaxen86•2mo ago

Well depends on what you do in the async functions. I'd say instead of setting a signal inside onMount I'd rather use the optimised primitive for async. Resulting in less lines of code, also plays nicely with Suspense. But it depends on the use case.

hyperknotOP•2mo ago

I just use it to set up external things, like init functions on first app load, etc. Nothing to do with signals or stores.

Brendonovich•2mo ago

I’d say it depends on whether you want to wait for onMount to complete or not. Async onMount will run in the background after rendering, but sometimes that’s fine

hyperknotOP•2mo ago

I don't need to wait for them, so onMount is good in my case, but I'd like to know in what order are the following bits: - DOM elements added - sync onMount - async onMount - createResource - createEffect What I did experiment with is that if there is an async onMount and a child component also has an onMount, then the parent element's onMount processes all the lines until the first await. Then the child component takes over, mounts, and gives back processing to the parent. I tested with alert() to stop the main thread.

bigmistqke•2mo ago

What I did experiment with is that if there is an async onMount and a child component also has an onMount, then the parent element's onMount processes all the lines until the first await. Then the child component takes over, mounts, and gives back processing to the parent.

yes, this is how await operates and is not directly related to solid's scheduling: when you call "await" it will pause that execution and yield control back to the event loop. once the promise is resolved it continues from where you called await

hyperknotOP•2mo ago

Thanks. What's not clear is what runs before and after rendering. By "rendering" I mean updating the DOM. From the list above, do all of them run after the DOM has been updated?

bigmistqke•2mo ago

Both createEffect and onMount run at the same time: after rendering. onMount is like a createEffect that isn't listening to any signals. ~~I am not sure actually when the callback in createResource is called~~ I checked the docs and it says it's called immediately. That is then the same as createMemo. createRenderEffect is also called immediately, just like createComputed.

createResource -

Documentation for SolidJS, the signals-powered UI framework

hyperknotOP•2mo ago

Thank you!

bigmistqke•2mo ago

You are very welcome!

Gaming

Programming

Async in onMount OK?

Did you find this page helpful?