Skip to content

Commit

Permalink
feat: added better errors when no state generation functions are prov…
Browse files Browse the repository at this point in the history
…ided

Users should now get more intelligible panics in such cases at Perseus
build time.
  • Loading branch information
arctic-hen7 committed Feb 17, 2022
1 parent b2f67e6 commit e565632
Showing 1 changed file with 8 additions and 6 deletions.
14 changes: 8 additions & 6 deletions packages/perseus-macro/src/template_rx.rs
Original file line number Diff line number Diff line change
Expand Up @@ -227,6 +227,7 @@ pub fn template_impl(input: TemplateFn, attr_args: AttributeArgs) -> TokenStream
FnArg::Typed(PatType { pat, ty, .. }) => (pat, ty),
FnArg::Receiver(_) => unreachable!(),
};
let name_string = name.to_string();
// Handle the case in which the template is just using global state and the first argument is the unit type
// That's represented for Syn as a typle with no elements
match &**rx_props_ty {
Expand Down Expand Up @@ -315,9 +316,9 @@ pub fn template_impl(input: TemplateFn, attr_args: AttributeArgs) -> TokenStream
// Again, frozen state has been dealt with already, so we'll fall back to generated state
::std::option::Option::None => {
// Again, the render context can do the heavy lifting for us (this returns what we need, and can do type checking)
// And we know that the properties will be provided if the user is expecting them, we just can't prove that to the compiler
// We also assume that this is valid because it comes from the server
render_ctx.register_page_state_str::<#rx_props_ty>(&props.path, &props.state.unwrap()).unwrap()
// We also assume that any state we have is valid because it comes from the server
// The user really should have a generation function, but if they don't then they'd get a panic, so give them a nice error message
render_ctx.register_page_state_str::<#rx_props_ty>(&props.path, &props.state.unwrap_or_else(|| panic!("template `{}` takes a state, but no state generation functions were provided (please add at least one to use state)", #name_string))).unwrap()
}
}
}
Expand All @@ -334,6 +335,7 @@ pub fn template_impl(input: TemplateFn, attr_args: AttributeArgs) -> TokenStream
FnArg::Typed(PatType { ty, .. }) => ty,
FnArg::Receiver(_) => unreachable!(),
};
let name_string = name.to_string();
quote! {
#vis fn #name<G: ::sycamore::prelude::Html>(props: ::perseus::templates::PageProps) -> ::sycamore::prelude::View<G> {
use ::perseus::state::MakeRx;
Expand Down Expand Up @@ -362,9 +364,9 @@ pub fn template_impl(input: TemplateFn, attr_args: AttributeArgs) -> TokenStream
// Again, frozen state has been dealt with already, so we'll fall back to generated state
::std::option::Option::None => {
// Again, the render context can do the heavy lifting for us (this returns what we need, and can do type checking)
// And we know that the properties will be provided if the user is expecting them, we just can't prove that to the compiler
// We also assume that this is valid because it comes from the server
render_ctx.register_page_state_str::<#rx_props_ty>(&props.path, &props.state.unwrap()).unwrap()
// We also assume that any state we have is valid because it comes from the server
// The user really should have a generation function, but if they don't then they'd get a panic, so give them a nice error message
render_ctx.register_page_state_str::<#rx_props_ty>(&props.path, &props.state.unwrap_or_else(|| panic!("template `{}` takes a state, but no state generation functions were provided (please add at least one to use state)", #name_string))).unwrap()
}
}
}
Expand Down

0 comments on commit e565632

Please sign in to comment.