Use Client Components in app directory api route
Unanswered
Sun bear posted this in #help-forum
Sun bearOP
Hello,
I’m currently trying to render a React component in an API route of my application, and I’m using
However, I ran into an issue where the API route cannot render client components. A helpful developer from
That said, I’d like to move away from the Pages Router and avoid having both a Pages and App directory in my project. I’m looking for a better solution that doesn’t require maintaining a Pages Router structure.
Does anyone have ideas or suggestions to help with this?
Thank you!
I’m currently trying to render a React component in an API route of my application, and I’m using
next-intl for this purpose. You can find an example here: [GitHub Repository](https://github.com/Tockra/nextjs-test-playground).However, I ran into an issue where the API route cannot render client components. A helpful developer from
next-intl suggested a workaround: using the Pages Router for API routes (as discussed here: [GitHub Discussion](https://github.com/amannn/next-intl/discussions/1273)). With this approach, everything works fine.That said, I’d like to move away from the Pages Router and avoid having both a Pages and App directory in my project. I’m looking for a better solution that doesn’t require maintaining a Pages Router structure.
Does anyone have ideas or suggestions to help with this?
Thank you!
5 Replies
@Sun bear Hello,
I’m currently trying to render a React component in an API route of my application, and I’m using `next-intl` for this purpose. You can find an example here: [GitHub Repository](https://github.com/Tockra/nextjs-test-playground).
However, I ran into an issue where the API route cannot render client components. A helpful developer from `next-intl` suggested a workaround: using the Pages Router for API routes (as discussed here: [GitHub Discussion](https://github.com/amannn/next-intl/discussions/1273)). With this approach, everything works fine.
That said, I’d like to move away from the Pages Router and avoid having both a Pages and App directory in my project. I’m looking for a better solution that doesn’t require maintaining a Pages Router structure.
Does anyone have ideas or suggestions to help with this?
Thank you!
why would you need to render react in an api route? you can just use a normal page,
app/api/foo/page.tsx works@joulev why would you need to render react in an api route? you can just use a normal page, `app/api/foo/page.tsx` works
Sun bearOP
Because I want to print it into a PDF file and send it back as response.
I provide it to pupeteer and it prints it to pdf.
The data flow is something like this:
User -> GET request -> server receives data from other backend -> server renders react component with received data -> server puts rendered html to puppeteer -> server prints rendered page to pdf -> server returns PDF file to the user
Puppeteer cannot run on the client side. Additionally, providing a helper page for Puppeteer to visit is not straightforward due to the large amount of data that needs to be passed to the component. The only feasible way to transmit this data to the page being visited by Puppeteer is through query parameters or path parameters. However, both methods have limitations in terms of maximum length.
So I render the component with @fileforge/react-print in the server component and I can pass the data as property, which has no limits.
I provide it to pupeteer and it prints it to pdf.
The data flow is something like this:
User -> GET request -> server receives data from other backend -> server renders react component with received data -> server puts rendered html to puppeteer -> server prints rendered page to pdf -> server returns PDF file to the user
Puppeteer cannot run on the client side. Additionally, providing a helper page for Puppeteer to visit is not straightforward due to the large amount of data that needs to be passed to the component. The only feasible way to transmit this data to the page being visited by Puppeteer is through query parameters or path parameters. However, both methods have limitations in terms of maximum length.
So I render the component with @fileforge/react-print in the server component and I can pass the data as property, which has no limits.
@Sun bear Because I want to print it into a PDF file and send it back as response.
I provide it to pupeteer and it prints it to pdf.
The data flow is something like this:
User -> GET request -> server receives data from other backend -> server renders react component with received data -> server puts rendered html to puppeteer -> server prints rendered page to pdf -> server returns PDF file to the user
Puppeteer cannot run on the client side. Additionally, providing a helper page for Puppeteer to visit is not straightforward due to the large amount of data that needs to be passed to the component. The only feasible way to transmit this data to the page being visited by Puppeteer is through query parameters or path parameters. However, both methods have limitations in terms of maximum length.
So I render the component with @fileforge/react-print in the server component and I can pass the data as property, which has no limits.
interesting one. yeah i don't think i'm able to propose a solution better than the one the next-intl maintainer proposed. after all having a pages folder and an app folder at the same time is fully supported and far from the end of the world
Sun bearOP
Since I updated Next.js from version 14 to 15, a new problem has appeared in the pages route.
When I call the
What’s strange is that this worked fine before the update to Next.js 15. The same
When I call the
compile function from @fileforge/react-print in a pages route (even with an empty tag like <></>), it fails with the following error:⨯ Error: Objects are not valid as a React child (found: object with keys {$$typeof, type, key, props, _owner, _store}). If you meant to render a collection of children, use an array instead.
at async handler (src/pages/api/test2.tsx:13:21)
11 | .default;
12 | const timeZone = Intl.DateTimeFormat().resolvedOptions().timeZone
> 13 | const htmlString = await compile(
| ^
14 | <></>
15 | );
16 | res.status(200).json(htmlString); {
page: '/api/test2'What’s strange is that this worked fine before the update to Next.js 15. The same
compile function works correctly in the app route, so the issue seems to be isolated to the pages route after the update.Sun bearOP
Hm I build a workaround. I just use the
const messages = useMessages() object and pass it to my pdf components manually as property. This way I can use the app directory router again and there the compile function works again.