Skip to content

feature flag blitz-shell behind new shell feature#5650

Open
rydb wants to merge 1 commit into
DioxusLabs:mainfrom
rydb:main
Open

feature flag blitz-shell behind new shell feature#5650
rydb wants to merge 1 commit into
DioxusLabs:mainfrom
rydb:main

Conversation

@rydb

@rydb rydb commented Jun 23, 2026

Copy link
Copy Markdown

pr addresses the following issue:
#5647

This pr feature flags blitz-shell in dioxus-native behind a new shell feature(which is set to default for feature parity with present behavior).

If this pr is merged, blitz-shell and winit will become optional dependencies of dioxus-native and will no longer require double compile winit if you use a framework downstream with a different winit version(e.g; bevy).

All shell implementation related code is moved into a new /shell folder to minimize cfg flags and separate it from the rest of dioxus-native.

@rydb rydb requested a review from a team as a code owner June 23, 2026 18:00
@nicoburns

nicoburns commented Jun 23, 2026

Copy link
Copy Markdown
Member

@rydb Hmm... my intention was for the dioxus-native-dom crate to serve this use case (it contains the core integration of dioxus with blitz-dom without the shell stuff. Are there particula things in dioxus-native that are not in dioxus-native-dom that you wanted to use? (or were you perhaps not aware of dioxus-native-dom?)

@rydb

rydb commented Jun 23, 2026

Copy link
Copy Markdown
Author

@rydb Hmm... my intention was for the dioxus-native-dom crate to this use case (it contains the core integration of dioxus with blitz-dom without the shell stuff. Are there particulary things in dioxus-native that are not in dioxus-native-dom that you wanted to use? (or were you perhaps not aware of dioxus-native-dom?)

I did have it in my codebase, but It didn't register with me to use it. However, while trying to swap out dioxus-native for dioxus-native-dom, I noticed dioxus_asset_resolver is feature flagged behind native, and so I would need to pull in dioxus-native in order to make a NetProvider impl for my crate regardless:

impl NetProvider for BevyNetProvider {
    fn fetch(
        &self,
        _doc_id: usize,
        request: blitz_traits::net::Request,
        handler: Box<dyn NetHandler>,
    ) {
        match request.url.scheme() {
            // Load Dioxus assets
            "dioxus" => match dioxus_asset_resolver::native::serve_asset(request.url.path()) {
                Ok(res) => handler.bytes(request.url.to_string(), res.into_body().into()),
                Err(err) => {
                    warn!("{err}");
                }
            },
            ... rest of impl
}
cannot find `native` in `dioxus_asset_resolver`
could not find `native` in `dioxus_asset_resolver`
lib.rs(36, 9): found an item that was configured out
#[allow(unused)]
pub fn asset_path(asset: impl ToString) -> Result<PathBuf, AssetPathError> {
    #[cfg(all(feature = "web", target_arch = "wasm32"))]
    return Err(AssetPathError::CannotRepresentAsPath);

    #[cfg(feature = "native")]
    return native::resolve_native_asset_path(asset.to_string().as_str());

    Err(AssetPathError::NotFound)
}

would it make sense to:

  • unify these two crates:
    It didn't click with me to use dioxus-native-dom because both of these crates have a DioxusDocument and I personally defaulted to dioxus-native's DioxusDocument because I thought that was the one I was meant to use in-line with what I'm used to with dioxus-desktop.

or

  • move asset_path/resolution to dioxus-native-dom:
    This is the only thing that blocking me fully using dioxus-native-dom instead of dioxus native at the moment.

I think for consistency with, e.g; dioxus-desktop, it might be worth unifying these crates. Looking at the difference of this crate pre and post shell feature flag, the non-shell feature flagged content inside it is pretty slim at only around ~200 lines.

@nicoburns nicoburns added the native Related to dioxus-native label Jul 6, 2026
@nicoburns

Copy link
Copy Markdown
Member

@rydb I think you just need to enable the native feature of the dioxus-asset-resolver crate.

I think we could also refactor the code so that the core of the NetProvider lives in dioxus-native-dom (abstract out the ShellProvider and compose that back in in dioxus-native). Although I suspect in your case you'll want a custom NetProvider anyway to support Bevy-specific stuff?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

native Related to dioxus-native

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants