Render emails in Next JS client component throws at renderToStaticMarkup

[RomainGueffier]

Describe the Bug

I have a bug since upgrating to Next JS 14.x with @react-email/render on client side.
I already saw similar issues but none of them really address my use case scenario.

I have monorepo project with an @email package full of react-email components exported as react. I need to render them at runtime to pass dynamic props.
With react-hook-form onSubmit I send as POST body to my mailer api the stringified html of my emails templates rendered on the spot. I will share later usage example, but see simple reproducing repo.

Since next 14 I have this error:

Error: Internal Error: do not use legacy react-dom/server APIs. If you encountered this error, please open an issue on the Next.js repo.
    at Object.r [as renderToStaticMarkup]

Maybe it was not intended for render to be used in the client bundle, but until now it was working fine. Advice on my usage is welcome.

Note: I can't revert to next 13 as there is serious issues with ISR cache.

Thanks for your awesome work to make email templating world easier 👍🏼

Which package is affected (leave empty if unsure)

@react-email/render

Link to the code that reproduces this issue

https://github.com/RomainGueffier/react-email-next-14

To Reproduce

Install and run project
In home page, visit server page => will work
In home page, visit client page => click show/hide template see console error shows error, crash

Expected Behavior

Be able to render emails as string in client side

What's your node version? (if relevant)

20

[RomainGueffier]

here is a hook sending email in my real app:

import { useState } from 'react'
import { SubmitHandler, useForm } from 'react-hook-form'
import { zodResolver } from '@hookform/resolvers/zod'
import { useCustomer, useSendEmail } from '@org/hooks'
import { type ValidationSchema, validationSchema } from './validation'
// lib containing react-email components
import { emailContactTemplate, type ContactEmailProps } from '@org/emails'

const useContactForm = () => {
  const {
    register,
    reset,
    handleSubmit,
    formState: { errors },
  } = useForm<ValidationSchema>({
    resolver: zodResolver(validationSchema),
  })
  const { sendEmail, isLoading } = useSendEmail()
  const { customer } = useCustomer()

  const onSubmit: SubmitHandler<ValidationSchema> = async ({
    firstname,
    lastname,
    ...rest
  }) => {
    const name = `${firstname} ${lastname}`

    const emailData = {
      customer: customer,
      data: {
        name,
        ...rest,
      },
      previewText: 'Demande de renseignements depuis votre site internet',
    } satisfies ContactEmailProps

    // fetch wrapper hook to send content with external api
    const result = await sendEmail({
      to: customer.email,
      subject: 'Demande de renseignements depuis votre site internet',
      text: emailContactTemplate.toText(emailData), // wrapper for @react-email/render
      html: emailContactTemplate.toHtml(emailData), // wrapper for @react-email/render
    })
    reset()
  }

  return {
    onSubmit,
    register,
    handleSubmit,
    errors,
    isLoading,
  }
}

export default useContactForm

[VaniaPopovic]

I think this might be the same issue that I'm having here #1054 . There's a PR for a fix, that should be released pretty soon. #1079

[gabrielmfern]

I think this might be the same issue that I'm having here #1054 . There's a PR for a fix, that should be released pretty soon. #1079

I think this isn't a duplicate of #1054. This is a client side-issue, #1054 was a server-side one.

[gabrielmfern]

From what I've gathered of this issue what's happening is that Next stubs the renderToStaticMarkup and renderToString react-dom/server functions to throw this error for them to avoid usage of these functions on their code but it causes this error for us as well.
On the server we can use other functions to avoid this issue but on the client there is really no alternative unless we use something that is not React specific for rendering. Maybe we should consider opening an issue on the Next repo for this

[gabrielmfern]

@RomainGueffier What happens if you use renderAsync for this instead?

[RomainGueffier]

@RomainGueffier What happens if you use renderAsync for this instead?

Didn't think about it, it just works 😱. If so, it is a life saver alternative as this bug is show-stopper for us.

I did push in reproduction repo an updated test with renderAsync usage :

• code: https://github.com/RomainGueffier/react-email-next-14
• preview: https://romaingueffier.github.io/react-email-next-14/

I put 6 use cases including server and client with both render and renderAsync

Edit: it does not work for both case in safari

[Error] TypeError: ReadableByteStreamController is not implemented — 833-c8e66b6a37b3d4b4.js:21:208229
	(fonction anonyme) (472-0a5a1881c82c5cac.js:1:3789)
	ig (833-c8e66b6a37b3d4b4.js:21:170551)
	iS (833-c8e66b6a37b3d4b4.js:21:171813)
	iW (833-c8e66b6a37b3d4b4.js:21:194735)
	(fonction anonyme) (833-c8e66b6a37b3d4b4.js:21:209461)
	Promise
	(fonction anonyme) (833-c8e66b6a37b3d4b4.js:21:204775)
	(fonction anonyme) (833-c8e66b6a37b3d4b4.js:29:82208)
	s (833-c8e66b6a37b3d4b4.js:29:81311)

[RomainGueffier]

Edit: it does not work for both case in safari

[Error] TypeError: ReadableByteStreamController is not implemented — 833-c8e66b6a37b3d4b4.js:21:208229
	(fonction anonyme) (472-0a5a1881c82c5cac.js:1:3789)
	ig (833-c8e66b6a37b3d4b4.js:21:170551)
	iS (833-c8e66b6a37b3d4b4.js:21:171813)
	iW (833-c8e66b6a37b3d4b4.js:21:194735)
	(fonction anonyme) (833-c8e66b6a37b3d4b4.js:21:209461)
	Promise
	(fonction anonyme) (833-c8e66b6a37b3d4b4.js:21:204775)
	(fonction anonyme) (833-c8e66b6a37b3d4b4.js:29:82208)
	s (833-c8e66b6a37b3d4b4.js:29:81311)

Seems like using a polyfill can fix it in safari for now: https://github.com/MattiasBuelens/web-streams-polyfill

[gabrielmfern]

Seems like using a polyfill can fix it in safari for now: https://github.com/MattiasBuelens/web-streams-polyfill

That's really helpful, we'll probably use something like that for the renderAsync to be supported better.