SSR with app router

Sorry about that, they’re fixed now!

@samuel_pullman Does usePlasmicQueryData still need to be used, or can I convert the component to async/await instead? Since usePlasmicQueryData is client-side, I’m wondering if we can switch to a server-side async component approach.

If you are currently using usePlasmicQueryData in code components for SSR, then you’ll want to start moving your data fetching logic to an independent async function and register it with registerFunction instead. Then, in the page you want to fetch data from, you’ll use your registered function.

Plasmic cannot support custom server components with async/await functionality.

@jason @alex_noel

Is there any plan to support Server Components with async/await data fetching in the future?

In modern Next.js applications, React Server Components play a critical role in improving performance, SEO, and reducing client-side bundle size. Being able to fetch data directly in Server Components using async/await allows rendering the page with fully resolved data on the server without relying on client-side data fetching.

Currently, when integrating Plasmic with client-side rendering or client-side data fetching, it introduces additional hydration overhead and can negatively impact performance for content-heavy or SEO-critical pages.

For many production websites, especially those relying on SSR or RSC patterns, server-side data fetching within components is essential to maintain optimal performance and scalability.

It would be helpful to know if there are any plans to support Server Components with async/await data fetching so that Plasmic components can participate in the React Server Component architecture without requiring client-side wrappers or workarounds.

1 Like

@lokesh_mudgal Following Jason’s advice about using registerFunction with data fetching/async functions means you can do server-side data fetching without client wrappers/workarounds, this is the recommended way moving forward.

@samuel_pullman @jason can you share an exmple proj in which we are registering async function. And how we are calling in code picker.

currently i have registered a async function with data fetch logic, i am calling like this ( shared screen shoot ) for a prop, getting this

am i doing a right way ?

it would be great if you share an sample of this.

i even tried adding, add the end of function . (shared in above SC)

.then((result) => result);

but that also giving nothing

You shouldn’t need to edit code in Studio like this.

If your registerFunction call includes isQuery: true, it should show up on the new “Data queries” panel on the right tab.

@jason @samuel_pullman added the isQuery: true in register function call, it is not showing Data query.
Do i need add an integration too for that ? as we have not added any api call integration to plasmic.

please let me know what am i doing wrong here.

function registered as :

PLASMIC.registerFunction(getProductListingCarouselData, {
  name: "getProductListingCarouselData",
  params: [
    { name: "opts", type: "object", description: "Options: dynamicSlicesData, categorySlug, productCount, identifier, viewType, country" },
  ],
  returnValue: { type: "object", description: "Returns { products, conversionRates, selectedCategory }" },
  importPath: "@helpers/plasmic/products",
  isQuery: true,
});

then trying to call it from component prop.

  • from productListingData prop - clicked on useDynamicValue
  • then from select data modal, selected “Add new data query”.

function is registered as in edit if i am trying to call it then it is shown in suggestion.

Currently you must add the data query to a page, but we are working on allowing data queries on a component as well.

You will find the new data queries on the right panel in “Page data”.

Alright Thanks.

@jason @alex_noel i saw your team made this update live for all on friday. v2.0.0.

why the function name is still unstable__generateMetadata ? is this version is still not completely stable or unsafe to use ?

@lokesh_mudgal The loader syntax and naming will not change, but all RSC-related functions remain marked as unstable__ just because they’re under active development and are a subject to change.
But that doesn’t mean they are unsafe to use