Lint tokio error or update tokio compilation error message

[ealmloff]

Specific Demand

It is very common for people to try to use Tokio in Dioxus (or wasm more generally). If you try to compile the project after adding tokio, you get this crypic error message:

unresolved import `crate::sys::IoSourceState`
   |
12 | use crate::sys::IoSourceState;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^ no `IoSourceState` in `sys`

Implement Suggestion

We should either change Tokio's error message when too many Tokio features are enabled for wasm support or look for the Tokio dependency when we compile a project in the CLI and warn users about Tokio not fully supporting wasm

[nubunto]

how would I go about having dioxus_desktop and dioxus_web in the same main.rs? just stumbled on this while trying out dioxus.

Just figured it out. In your Cargo.toml:

[dependencies]
dioxus = "0.4.3"
dioxus-web = "0.4.3"

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
dioxus-desktop = "0.4.3"

[dan-da]

I just hit this error. I have to pull in another crate that uses tokio heavily (including multi-thread runtime) in order to get some necessary types. Presently the dep crate is using tokio feature "full", but it probably doesn't have to. Now its unclear to me how to get my dioxus project to build or if its even possible. Is there guidance somewhere on what tokio/mio features are wasm compatible or not?

edit: tokio documents wasm compat here: https://docs.rs/tokio/latest/tokio/#wasm-support

One option might be to break up the dep crate into separate crates, but I'm hoping to avoid that.

[painedpineapple]

I've been hammering at this for hours and nothing seems to work. @dan-da do you have an example of what other dep you installed to get this to work? The basic SSR example in the dioxus learn site results in this error (https://dioxuslabs.com/learn/0.5/reference/ssr). I've attempted this on macOS and Linux and still nothing works.

[ealmloff]

The basic SSR example in the dioxus learn site results in this error (https://dioxuslabs.com/learn/0.5/reference/ssr)

If you are trying to create a fullstack application that compiles to both a server and a client, the fullstack crate is much easier to set up. If you need to set up SSR manually, you will need to set up a feature that enables the tokio dependency only on the server. Fullstack set up a server feature that does this for you here

[painedpineapple]

Thanks @ealmloff, that's what I needed. It looks like I'll need to setup SSR manually since there doesn't appear to be a way to serve meta/other head tags from the server w/out it. Looks like I can do that using pre_cache_static_routes.

[ealmloff]

Thanks @ealmloff, that's what I needed. It looks like I'll need to setup SSR manually since there doesn't appear to be a way to serve meta/other head tags from the server w/out it. Looks like I can do that using pre_cache_static_routes.

If you have global tags throughout your site, you can create an index.html file with whatever meta tags you need and dioxus-fullstack will pick it up automatically. If you need to set different tags in the head per route, you will need to roll some custom rendering code. Either way you can still re-use some of the code for serving static files and server functions from the fullstack axum adapter

[painedpineapple]

Gotcha, okay. Random other Q. Do you need to install dioxus_fullstack separate or can you just enable the "fullstack" feature on dioxus in cargo.toml?

[ealmloff]

Gotcha, okay. Random other Q. Do you need to install dioxus_fullstack separate or can you just enable the "fullstack" feature on dioxus in cargo.toml?

You can just enable the fullstack feature. If you enable multiple features like fullstack and router instead of pulling in the crates, dioxus will enable the integration features for you