Enable serve_dioxus_application for WASM targets

[DrewRidley]

Motivation
Currently, WASM servers cannot use serve_dioxus_application because it's trait extension only has an implementation for non-WASM targets. If users try to manually implement this functionality, they encounter difficulty accessing the private context_providers field in the ServeConfig, and have to rewrite a lot of the core logic for SSR which has a maintenance burden.

Solution

This PR adds conditional compilation for the serve_static_assets method:

• For non-WASM targets: maintains the existing implementation that serves static assets from the public directory
• For WASM targets: provides a simple implementation that just returns self (no-op)

This allows WASM servers to use the same serve_dioxus_application API as non-WASM servers, simplifying code that needs to work across both environments. Since this trait is never used on wasm currently, it should not introduce a breaking change.

[ealmloff]

I can see how exposing the logic to handle server functions and the default route renderer is useful in wasm, but the serve_static_assets function is documented as serving static assets which we can't do in wasm servers. How about a new method with the same signature on DioxusRouterFnExt that just serves the fullstack server function and rendering endpoints instead?

[DrewRidley]

After re-reading the comment, I would have to agree that this approach makes more sense.
The requested changes have been implemented, and compilation it was tested with:

--target wasm32-unknown-unknown --no-default-features --features document,core

Let me know if theres anything else I can do!

[DrewRidley]

Those two tests seem to be failing on main also, is there anything I need to change in this PR?

Also, I was wondering if I could incorporate a fullstack-core feature for dioxus which does all the feature gating for wasm targets, just to massively simplify the cargo.toml for applications targeting wasm for SSR.

[ealmloff]

Looks great, thanks! Workflow failures are unrelated.

[ealmloff]

Also, I was wondering if I could incorporate a fullstack-core feature for dioxus which does all the feature gating for wasm targets, just to massively simplify the cargo.toml for applications targeting wasm for SSR.

I think that would make sense. What is your setup for serving a fullstack app with a wasm backend? We look for the fullstack feature in the CLI to determine what platform you are serving. We don't support wasm backends in the CLI, and at this point the tooling seems like it is tied to each backend provider so I don't think it makes sense to add support yet. If we don't change the CLI and just add the feature, dx serve will launch the app as a web app which will panic immediately because there is no hydration.

[DrewRidley]

Atm, I have to do:

dioxus = { git = "https://github.com/DrewRidley/dioxus.git" }
dioxus-server = { git = "https://github.com/DrewRidley/dioxus.git", features = [
	"document",
	"core",
], default-features = false }
dioxus-router = { git = "https://github.com/DrewRidley/dioxus.git", features = [
], default-features = false }
dioxus_server_macro = { git = "https://github.com/DrewRidley/dioxus.git", features = [
], default-features = false }
server_fn = { version = "0.8.2", features = ["axum-no-default", "browser"] }

In my code on my own app, which is a bit cumbersome, and makes it harder to mix regular fullstack with cloudflare. Ideally theres some way to directly target features for a wasm server, and it would be even better if it could be hooked into the dx cli to automatically build and hot patch a wasm server binary, but that might be something for the future.

Thanks for merging the PR. Let me know if there is any interest in a more direct integration, I would be happy to explore the idea further and potentially put forward a follow-up PR.