feat: Allow disabling server fn hash and customizing the default prefix #3438
Conversation
Allow configuring the default prefix for server function API routes. This is useful to override the default prefix (`/api`) for all server functions without needing to manually specify via `#[server(prefix = "...")]` on every server function. Also, allow disabling appending the server functions' hashes to the end of their API names. This is useful when an app's client side needs a stable server API. For example, shipping the CSR WASM binary in a Tauri app. Tauri app releases are dependent on each platform's distribution method (e.g., the Apple App Store or the Google Play Store), which typically are much slower than the frequency at which a website can be updated. In addition, it's common for users to not have the latest app version installed. In these cases, the CSR WASM app would need to be able to continue calling the backend server function API, so the API path needs to be consistent and not have a hash appended.
Add support to configure and set the `SERVER_FN_PREFIX` and `DISABLE_SERVER_FN_HASH` env vars using the leptos project config. See the following PR for more info: leptos-rs/leptos#3438
Add support to configure and set the `SERVER_FN_PREFIX` and `DISABLE_SERVER_FN_HASH` env vars using the leptos project config. See the following PR for more info: leptos-rs/leptos#3438
| @@ -78,6 +78,12 @@ pub struct LeptosOptions { | |||
| #[builder(default = default_hash_files())] | |||
| #[serde(default = "default_hash_files")] | |||
| pub hash_files: bool, | |||
| #[builder(default, setter(strip_option))] | |||
There was a problem hiding this comment.
LeptosOptions should be marked as non-exhaustive so fields can be added without requiring a breaking semver update. However, adding a non-exhaustive annotation is also a breaking change. I’m happy to add it if you want, and if there’s another version bump coming up I can switch this PR to that branch if one exists.
There was a problem hiding this comment.
It'd probably be good to add, the release of 0.8 is likely soonish
|
Overall I think this looks good and would be a useful change. The hashes were added by default primarily to prevent collisions between server fn paths. Have you experimented to see what happens in that case? If I recall correctly it should throw an error. Otherwise I think this is good to go |
Yeah, Axum throws an error when you try to add a duplicate route. I can add a comment calling this out. I think it’s okay though since removing the hashes is an opt-in behavior. I was thinking another option to prevent conflicts could be to use the module path as the prefix for the api route. From what I was seeing though that’s not possible in macros, but I’m not super familiar with macros so I could be wrong. |
A comment's good, overall I don't think we have to worry about additional conflict detection as long as it throws a proper error |
I was double checking this, and I was correct that Axum throws an error. However, it appears that Actix doesn't. In that case, do we want to add a check somewhere in Leptos? |
I actually figured out how to do this. It would require adding const-str as a dependency in Here's the code: spencewenski#1. I'll move the PR to the main leptos repo once this PR is merged. |
Allow configuring the default prefix for server function API routes. This is useful to override the default prefix (
/api) for all server functions without needing to manually specify via#[server(prefix = "...")]on every server function.Also, allow disabling appending the server functions' hashes to the end of their API names. This is useful when an app's client side needs a stable server API. For example, shipping the CSR WASM binary in a Tauri app. Tauri app releases are dependent on each platform's distribution method (e.g., the Apple App Store or the Google Play Store), which typically are much slower than the frequency at which a website can be updated. In addition, it's common for users to not have the latest app version installed. In these cases, the CSR WASM app would need to be able to continue calling the backend server function API, so the API path needs to be consistent and not have a hash appended.
I also opened a
cargo-leptosPR to add support for setting the env vars based on values in the leptos config: leptos-rs/cargo-leptos#412