next-intl: react-server: throws an exception when using `use`

Description

I suspect this line of code is throwing unhandled exceptions from the use method.

At least our Sentry is giving this:

image

And I suspect this might be on the middleware or somewhere. I of course, have no idea where exactly on your code, but hey, might be fun to investigate.

Mandatory reproduction URL (CodeSandbox or GitHub repository)

https://github.com/nodejs/nodejs.org

Reproduction description

  1. Navigate to /
  2. Apparently the Error is suppressed, so you can’t see them anywhere (console logs, etc) but Sentry is capturing them, so I suspect this should be handled differently.

I also see no documentation on react.dev around use, what is it and what it does?

Expected behaviour

No Exceptions

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Comments: 24 (5 by maintainers)

Most upvoted comments

Sentry maintainer here. I think we somehow need to ignore these errors inside the Sentry SDK. They are a react mechanism and used for control flow (e.g. throwing promises is used for suspense).

Sentry maintainer here. I think we somehow need to ignore these errors inside the Sentry SDK. They are a react mechanism and used for control flow (e.g. throwing promises is used for suspense).

What I wonder, Luca, is. If these are being thrown inside react itself, is it due to something being done erroneously?

I honestly don’t think so. I know way too little about RSCs yet (as probably everybody else) to make a 100% call on this but I would say that this is just how React works now with Suspense boundaries and we need to work around it.

I can imagine that by turning certain components into client components you disabled the mechanism that throws this “Error”.

Sentry maintainer here. I think we somehow need to ignore these errors inside the Sentry SDK. They are a react mechanism and used for control flow (e.g. throwing promises is used for suspense).

What I wonder, Luca, is. If these are being thrown inside react itself, is it due to something being done erroneously?

IO don’t think it hurts to test a patched version of next-intl that does a different behaviour.

Sure, you can use patch-package and modify next-intl/dist/esm/react-server/useHook.js accordingly in your code base (the ESM build is used for the react-server condition).

Let me know if that makes a difference!

Here are the docs for use.

Earlier this week, I’ve improved the docs for the RSC integration, this might help to provide some context: Using internationalization in Server Components

Generally, you can pick between an async and a hooks-based API, based on if you use APIs from next-intl in async or shared components (the latter allows to use non-stateful hooks, like useId—and also useTranslations).

The code snippet you’ve linked to points to error handling I’ve added, back when React/Next.js didn’t explain much when a user tries to accidentally use hooks in an async component. The error message still isn’t great, but at least the React ESLint plugin shows an error now:

Screenshot 2023-11-09 at 17 48 29

Due to this, we could consider removing the custom error handling now, but I’m wondering if Sentry would catch the promises that React/Next.js throws for various APIs like use, redirect etc. anyway. Maybe there’s something to adapt on the Sentry side.

EDIT: The ESLint rule upgrade doesn’t seem to be available in eslint-plugin-hooks@latest. Might make sense to wait at least for that before removing error handling from next-intl.