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

Serialize errors we encounter #66

Merged
merged 1 commit into from
Nov 17, 2023
Merged

Serialize errors we encounter #66

merged 1 commit into from
Nov 17, 2023

Conversation

bcspragu
Copy link
Collaborator

This PR makes it so that we serialize errors if we're going to send them across the SSR boundary. The problem this fixes is that some errors (like Nuxt reporting composable usage outside a setup function) have functions and other non-POJO/non-serializable info with them, which makes our useState<Error> implode, ironically hiding the original error.

This introduces a new non-dev dependency (which I don't do lightly) on serialize-error, a small (<1kB min + gzip'd) and popular dependency for doing the surprisingly nontrivial task of serializing different types of errors and preserving type information.

@bcspragu bcspragu marked this pull request as ready for review November 17, 2023 21:54
@bcspragu bcspragu requested a review from gbdubs November 17, 2023 21:54
Copy link
Contributor

@gbdubs gbdubs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solid solution, would it be possible to port this to our other projects? I know we run into this intermittently across every single surface

This PR makes it so that we serialize errors if we're going to send them across the SSR boundary. The problem this fixes is that some errors (like Nuxt reporting composable usage outside a `setup` function) have functions and other non-POJO/non-serializable info with them, which makes our `useState<Error>` implode, ironically hiding the original error.

This introduces a new non-dev dependency (which I don't do lightly) on `serialize-error`, a small (<1kB min + gzip'd) and popular dependency for doing the surprisingly nontrivial task of serializing different types of errors and preserving type information.
@bcspragu bcspragu changed the base branch from brandon/reorder to main November 17, 2023 23:44
@bcspragu
Copy link
Collaborator Author

would it be possible to port this to our other projects?

Most definitely! I want to let it marinade here a bit to make sure it does what I hope it will do in a variety of use cases (including trying to render specific errors based on type on the client after hydration), but we'll see

@bcspragu bcspragu merged commit 1672438 into main Nov 17, 2023
2 checks passed
@bcspragu bcspragu deleted the brandon/serial branch November 17, 2023 23:46
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.

2 participants