feat: make struct name and path optional for server functions #1573
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes the behavior of the
#[server]
macro to do two things:/
to/api
As a result, you can now write
as
Generating struct names is arguably bad proc-macro hygiene, which is why I didn't do it in the first place. The
#[component]
macro also does this when it generates a type name for ComponentProps, but this type name doesn't need to be referred to by the user. Server function types are more often used explicitly:Still, I think this is probably better. And rust-analyzer is, of course, smart enough to bring you directly to the
#[server]
macro for the correct function if you "Go to Definition" onDeleteTodo
in this example.Re:
/
vs/api
, mounting server functions at/
by default was probably never the right idea. Our starter templates all default to/api
. This will be a breaking change for anyone who was relying on that default mount point, but is easily addressed by moving that to/api
.