Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error Capturing Caveats #3141

Merged
merged 2 commits into from
Jan 21, 2025
Merged

Error Capturing Caveats #3141

merged 2 commits into from
Jan 21, 2025

Conversation

Gwynerva
Copy link
Contributor

@Gwynerva Gwynerva commented Jan 8, 2025

Some additions related to error capturing in Vue. See issue.

Error capturing caveats. See [issue](vuejs/core#12575 (comment)).
Copy link

netlify bot commented Jan 8, 2025

Deploy Preview for vuejs ready!

Name Link
🔨 Latest commit 2af30fc
🔍 Latest deploy log https://app.netlify.com/sites/vuejs/deploys/678f61bffdca660008e8a680
😎 Deploy Preview https://deploy-preview-3141--vuejs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@Gwynerva Gwynerva changed the title Update options-lifecycle.md Error Capturing Caveats Jan 8, 2025
@Gwynerva
Copy link
Contributor Author

Gwynerva commented Jan 8, 2025

@edison1105 Described two caveats! The first one is about errors from setup and render, second one about hydration mismatches when trying to make child replacement from parent component!

@NataliaTepluhina NataliaTepluhina merged commit 7c4dade into vuejs:main Jan 21, 2025
5 checks passed
szymonlicau referenced this pull request in vuejs-translations/docs-pl Jan 21, 2025
* Update options-lifecycle.md

Error capturing caveats. See [issue](vuejs/core#12575 (comment)).

* Update src/api/options-lifecycle.md

---------

Co-authored-by: Natalia Tepluhina <[email protected]>
@Gwynerva Gwynerva deleted the patch-1 branch January 21, 2025 09:10
@marlokessler
Copy link

marlokessler commented Feb 13, 2025

Hi @Gwynerva thank you for raising this PR and bringing this info into the docs. I had the same error today and found your issue #12575 very helpful. You wrote in the docs, that render is executed after a failed setup only in an async component. However, I experienced that the described caveat only occurs for sync components (i.e. without top-level await) on server-side and client-side, but not for async components (i.e. with top-level await), again on both server-side and client-side.

Do I get something wrong here or should it rather be "In components without async setup() function (without top-level await)…"?

@Gwynerva
Copy link
Contributor Author

Gwynerva commented Feb 13, 2025

@marlokessler

You are right it seems render error appears even in sync components and I wrongly interpreted the ending of @edison1105 comment:

Regardless of whether the component is synchronous or asynchronous, the exception thrown in the setup function always comes first, followed by the exception in the render function.

For async server-side components it produces and error:

image

For async client-side components I guess <Suspense> catches an error and makes a patch before rendering can begin. But it only works when <Suspense> is the direct parent of errored child. If errored child is deep inside it will still cause another error (but not from render, yes).

So I guess the docs should be edited and point out, that setup and render errors will always be there, no matter async or sync components. And only having <Suspense> as direct parent might save from errors at render. @edison1105 please correct me if I am wrong.

I had the same error today and found your issue #12575 very helpful.

Key points from what I have learned struggling with this problem:

  1. Never rely on onErrorCaptured because it has a lot of strange behaviour with <Suspense> in combination with SSR.
  2. Create custom logic that can be computed in parent component setup, catching errors you expect and do not even render the child component you know will error. As for unexpected errors that are out of your checking mechanism in parent — just let them be and fix them as bugs.
  3. It is not possible to replace child component in parent at render time with SSR. As far as I'm concerned, it just can't "return to parent and replace". Once the render function of parent is called, it is not recalculated no matter what happens in child components.

@edison1105
Copy link
Member

So I guess the docs should be edited and point out, that setup and render errors will always be there, no matter async or sync components. And only having as direct parent might save from errors at render. @edison1105 please correct me if I am wrong.

Exactly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants