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

Allow any type that implements FromServerFnError as a replacement of the ServerFnError in server_fn #3274

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

ryo33
Copy link

@ryo33 ryo33 commented Nov 22, 2024

Closes #3270
Fixes #3153
Addresses #3155

  • Added FromServerFnError
  • Deprecate the ServerFnError::WrappedServerError variant and manual error conversion helpers
  • Removed ServerFnErrorErr::WrappedServerError and impl From<ServerFnError> for ServerFnErrorErr
  • Update server_fn_macros to use the FromServerFnError trait
  • Added ServerFnErrorErr::Middleware for a better context of the errors
  • Added an example in examples/server_fn_axum
  • cargo +nightly make check

The implementation is complete. The only breaking changes should be the third ones mentioned above, and other behaviors should remain retained as expected.

@ryo33 ryo33 marked this pull request as ready for review November 22, 2024 04:08
@ryo33 ryo33 changed the title Add FromServerFnError trait to server_fn crate Allow any type that implements FromServerFnError as a replacement of the ServerFnError in server_fn Nov 22, 2024
@ryo33
Copy link
Author

ryo33 commented Nov 22, 2024

@nicolas-guichard Hi, this fix is similar to #3253, but takes a different approach, addressing #3153 and #3155. It would be great if you could take a look and review whether this approach works.

Comment on lines +526 to +544
/// Converts the custom error type to a [`String`]. Defaults to serializing to JSON.
fn ser(&self) -> String {
serde_json::to_string(self).unwrap_or_else(|e| {
serde_json::to_string(&Self::from_server_fn_error(
ServerFnErrorErr::Serialization(e.to_string()),
))
.expect(
"error serializing should success at least with the \
Serialization error",
)
})
}

/// Deserializes the custom error type from a [`&str`]. Defaults to deserializing from JSON.
fn de(data: &str) -> Self {
serde_json::from_str(data).unwrap_or_else(|e| {
ServerFnErrorErr::Deserialization(e.to_string()).into_app_error()
})
}
Copy link
Author

Choose a reason for hiding this comment

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

Now, custom error types have a default implementation for error serialization using serde_json. ServerFnError overrides it by using FromStr and Display for backward compatibility.

Comment on lines +692 to +715
#[derive(Debug, Clone, Display, Serialize, Deserialize)]
pub enum MyErrors {
InvalidArgument(InvalidArgument),
ServerFnError(ServerFnErrorErr),
Other(String),
}

impl From<InvalidArgument> for MyErrors {
fn from(value: InvalidArgument) -> Self {
MyErrors::InvalidArgument(value)
}
}

impl From<String> for MyErrors {
fn from(value: String) -> Self {
MyErrors::Other(value)
}
}

impl FromServerFnError for MyErrors {
fn from_server_fn_error(value: ServerFnErrorErr) -> Self {
MyErrors::ServerFnError(value)
}
}
Copy link
Author

Choose a reason for hiding this comment

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

This is the new way to define a custom error type for server fns. It can used directly in the signature of server fn like -> Result<(), MyErrors> instead of -> Result<(), ServerFnError<MyErrors>.

@gbj
Copy link
Collaborator

gbj commented Nov 29, 2024

Thanks for this work!

While I have not had time to manually test it, and have not reviewed every line, this looks like it is the right approach, and it certainly seems to make custom errors more usable, which I think is great.

It comes at a slightly awkward time in our release cycle as we are planning a 0.7 release this weekend and this makes some breaking changes that won't have time to be tested in the beta/rc process before that release.

So here's my suggestion:

  • @benwis plans to test this out and we will welcome other testers and reviews
  • We will release 0.7 without this included
  • We will also plan a 0.8 some time in late December/early January, that includes the final version of this PR and any breaking-change-requiring bugfixes from 0.7

@ryo33
Copy link
Author

ryo33 commented Nov 30, 2024

Thank you for your feedback! That release schedule is reasonable to me.

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