Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demonstrate how to dispatch assets of the same extension to different Rust types #10595

Closed
alice-i-cecile opened this issue Nov 16, 2023 · 3 comments
Labels
A-Assets Load files from disk to use for things like images, models, and sounds C-Examples An addition or correction to our examples

Comments

@alice-i-cecile
Copy link
Member

          > So @bushrat011899, extending on my proposed use case a bit.
1. I have multiple types which should be stored as a .json file.

2. I want to parse the json file to determine what Rust type to load this in as, and then add it to a central collection.

Is that feasible with this PR?

@alice-i-cecile Yes that should be entirely possible:

  1. First you'd create a plain JSON AssetLoader to give you the parsed contents to inspect.
// Handle<JsonAsset> implied by .json file extension if
// `JsonAssetLoader` is configured to be default handler of .json
let my_data_json_handle = asset_server.load("data/my_data.json");
  1. Once loaded, you can then inspect the JSON data for whatever information you'd need to determine the type it should be:
let my_data_json = json_assets.get(&my_data_json_handle)?;

let serde_json::Value::String(magic_token) = my_data_json.get("magic_token")? else {
    return None;
};

// Can re-use the path value for DRY reasons
let path = my_data_json_handle.path().unwrap();

// All match arms need to have the same return type, using UntypedHandle to avoid an enum
let my_data_handle = match magic_token {
    "key_bindings" => asset_server.load::<KeyBindingsAsset>(&path).untyped(),
    "settings" => asset_server.load::<SettingsAsset>(&path).untyped(),
    "scoreboard" => asset_server.load::<ScoreboardAsset>(&path).untyped(),
    _ => my_data_json_handle.untyped(),
};

Some(my_data_handle)

I imagine you'd want an enum for the central collection, and that would probably be the type of my_data_handle in the above match statement instead of using UntypedHandle's. Additionally, this behaviour is extended to the LoadContext::load method, so you could put all of this functionality into a custom AssetLoader if the load_with_reader method @nicopap suggested in #10565 was added (would need another PR to add).

Originally posted by @bushrat011899 in #10153 (comment)

@alice-i-cecile alice-i-cecile added C-Examples An addition or correction to our examples A-Assets Load files from disk to use for things like images, models, and sounds labels Nov 16, 2023
@torsteingrindvik
Copy link
Contributor

torsteingrindvik commented Nov 17, 2023

I tried asking a similar question here: #9714 (comment)

My TL;DR is I wish I could just

let handle_foo: Handle<Foo> = asset_server.load("data/foo.json");
let handle_bar: Handle<Bar> = asset_server.load("data/bar.json");

@bushrat011899
Copy link
Contributor

I tried asking a similar question here: #9714 (comment)

My TL;DR is I wish I could just

let handle_foo: Handle<Foo> = asset_server.load("data/foo.json");
let handle_bar: Handle<Bar> = asset_server.load("data/bar.json");

@torsteingrindvik with #10153, you will be able to do this!

@torsteingrindvik
Copy link
Contributor

torsteingrindvik commented Feb 20, 2024

I am doing extensionless mapped to lots of types now so I'm not actively using e.g. json-to-many myself but recent PRs and tests added by @bushrat011899 means this can be closed I think

EDIT: Noticing the title says "Demonstrate how to" so I suppose an example is needed, haven't checked if any of the asset examples cover this feature right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Assets Load files from disk to use for things like images, models, and sounds C-Examples An addition or correction to our examples
Projects
None yet
Development

No branches or pull requests

3 participants