monaco-editor keeps loading if await is used in Next JS

I'm very new to NextJs and React. I'm trying to use monaco editor in one of my page.

It works well if I use this code

"use client"

import { getCode } from '@/lib/getTasks';
import Editor from '@monaco-editor/react';


const AppDetails = async ({ params }) => {
    // console.log(params)
    // const code = await getCode(params.taskid)
    // console.log(code)
    const code = "sample code"
    return (
        <div><Editor height="90vh" defaultLanguage="python" defaultValue={code} />;</div>
    )
}

export default AppDetails

But If I use an await function

"use client"

import { getCode } from '@/lib/getTasks';
import Editor from '@monaco-editor/react';


const AppDetails = async ({ params }) => {
    console.log(params)
    const code = await getCode(params.taskid)
    console.log(code)
    return (
        <div><Editor height="90vh" defaultLanguage="python" defaultValue={code} />;</div>
    )
}

export default AppDetails

The editor only showing Loading text. I can see the correct values being fetched using console.log

Expecting my editor to load the text

Solution

client components cannot be async functions.

Why can't Client Components be async functions?

We strongly considered supporting not only async Server Components, but async Client Components, too. It's technically possible, but there are enough pitfalls and caveats involved that, as of now, we aren't comfortable with the pattern as a general recommendation. The plan is to implement support for async Client Components in the runtime, but log a warning during development. The documentation will also discourage their use.

The main reason we're discouraging async Client Components is because it's too easy for a single prop to flow through the component and invalidate its memoization, triggering the microtask dance described in an earlier section. It's not so much that it introduces new performance caveats, but it makes all the performance caveats described above much more likely.

There is one pattern where we think async Client Components make sense: if you structure them in such a way that they're guaranteed to only update during navigations. But the only realistic way to guarantee this in practice is by integrating support directly into your application's router. So it's unclear to what extent this pattern will even be documented. At least for now.

In the future, we could unlock general support for async Client Components by compiling them to a specialized, generator-like runtime.