adds feature axum_core that compiles for wasm target exposing server functions and ssr
#3840
Conversation
ealmloff
added
enhancement
There was a problem hiding this comment.
Thanks for working on this! Re-exporting a different trait based on the feature flag can issues because features need to be additive. If we make the main axum extension trait a super trait of the wasm compatible axum trait it should fix that issue. The SSR rendering code should also be wasm compatible already so that could be included in the axum wasm feature flag. The main thing that is not compatible with wasm is serving the static files with tower-http. If we move that to a separate trait, the rest of the integration should work in wasm
|
@ealmloff Thanks for the review! updated the PR for the feedback, lmk if there's something more to adjust |
conectado
changed the title
server_fn_axum that compiles for wasm target exposing server functionsaxum_wasm that compiles for wasm target exposing server functions and ssr
There was a problem hiding this comment.
Looks much better! The name axum_wasm might be slightly confusing if you need to import it in non-wasm targets. Maybe just axum_core for the wasm compatible axum integration and axum if you have access to both axum and a filesystem for native targets targets?
I expect tests will fail here again because the default features of axum were removed from the workspace. Adding default-features = true to the dev dependencies that rely on them should fix the issue
ah nice! I struggled to find a better name. feedback applied and also cleaned up the dependencies of each feature a bit more |
conectado
changed the title
axum_wasm that compiles for wasm target exposing server functions and ssraxum_core that compiles for wasm target exposing server functions and ssr
|
Hopefully CI should be passing now! |
|
my bad! now it should work |
|
rebased and conflicts resolved |
|
I think CI failure right now is unrelated |
The current `axum` feature and `server` feature are incompatible with wasm32-unknown-unknown target due to: 1. depends on axum features not compatible with wasm 2. SSR requires reading the filesystem for index.html With this patch I add the `server_fn_axum` feature which disables SSR and enables targeting wasm32-unknown-unknown with server functions enabled. Note that for this to work, `server_fn` depends on `inventory` and as stated in this docs depending on the context you might need to expose and call [`__wasm_call_ctors`](https://docs.rs/inventory/latest/inventory/#webassembly-and-constructors) (I needed that specifically for cloudflare workers) change axum_server_fn feature for axum_wasm and include SSR tools there This change additionaly make axum_server_fn feature additive by exposing a different `DioxusRouterWasmExt` with only the wasm-compatible parts instead of exposing the `DioxusRouter` trait under the same name. Docs are updated to reflect this change. rename axum_wasm to axum_core and update docs fix typo re-enable default-features for axum in dioxus-cli re-enable axum default-features for liveview re-enable default-features for axum for playwright-tests
|
rebased and conflicts solved! :) |
|
Just checking in on this PR—let me know if there's anything else I can do to help get it merged. No rush, just asking! |
Looks great to me, just waiting for a review from Jon before this can be merged |
The current
axumfeature is incompatible with wasm32-unknown-unknown target due to depending ontower-httpfor serving static files.With this patch I add the
axum_corefeature which disablestower-httpfunctions and enables targeting wasm32-unknown-unknown with server functions enabled and ssr.Note that for this to work,
server_fndepends oninventoryand as stated in this docs depending on the context you might need to expose and call__wasm_call_ctors(I specifically needed that for Cloudflare workers)Right now the feature isn't exposed by the main crate, I'm using it including the fullstack crate explicitly, I could add it to the main crate too!