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.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants