Add an optional request URL mapping function to WASM asset io

[eero-lehtinen]

Objective

Allow post processing wasm asset request URLs to make it possible to add query strings.

Solution

The first steps to fixing #21730

Add a new property request_mapper to HttpWasmAssetReader. I made it dyn to not add needless generics, but I guess static dispatch might work too.

Some mapping could be added to the default asset loader too, but I figured there is no consensus on what to do there. I just wanted to add this to allow motivated users to implement some kind of cache busting manually.

Testing

Added this to the custom_asset_reader example and ran it on a web browser.

impl Plugin for CustomAssetReaderPlugin {
    fn build(&self, app: &mut App) {
        let mut file_hashes = HashMap::new();
        file_hashes.insert("assets/branding/icon.png", "c09n2309jv");
        let file_hashes = Arc::new(file_hashes);
        app.register_asset_source(
            AssetSourceId::Default,
            AssetSource::build().with_reader(move || {
                Box::new(HttpWasmAssetReader::new("assets").with_request_mapper({
                    let file_hashes = file_hashes.clone();
                    move |path| {
                        let mapped = file_hashes.get(path).map_or_else(
                            || Cow::Borrowed(path),
                            |hash| Cow::Owned([path, "?", hash].concat()),
                        );
                        info!("Mapped asset path '{}' to '{}'", path, mapped);
                        mapped
                    }
                }))
            }),
        );
    }
}

The alternative, more straight forward, and slightly less efficient way to do cache busting would be to just add the current game version to the query string. Maybe we could add a premade helper function for that.

Showcase

[kristoff3r]

This looks great, I need something like this for work.

Having a builtin cache busting solution would be great down the line, but that might be complicated/controversial, and this will allow experimenting in third party plugins.

[andriyDev]

Hmmm this feels hyper specific and overly generic lol.

What do you think about making this a new asset source instead? This would be like PathMappingAssetSource and it would be able to apply to any asset source instead of just web assets. The disadvantage is you need to support going to and from the path to handle asset events.

Edit: to clarify this would be a wrapper asset source so it would be generic over the inner asset source.

[eero-lehtinen]

That might be smarter yeah, I'll try it out.

[eero-lehtinen]

I can't really figure out a way to sensibly make the mapping happen at the AssetSource level. The path mapping would need to be done in the writers and readers, I think.

It seems pretty easy to make a wrapper for an AssetReader that modifies the paths. That doesn't even require changes to Bevy internals so could be done in an external crate plugin.