dioxus icon indicating copy to clipboard operation
dioxus copied to clipboard

Manganis: Add Flag To Disable Folder Optimization

Open DogeDark opened this issue 1 year ago • 6 comments

Adds a optimize_files option for FolderAsset e.g.

const FOLDER_OPTIONS: FolderAssetOptions = FolderAssetOptions::new().with_optimize_files(true);

If the flag is set, the file will go under minor processing. The flag defaults to true to maintain current behavior.

DogeDark avatar Dec 05 '24 04:12 DogeDark

~~I think we originally wanted Folders to retain their asset names internally but have a different name externally - did that change? I'm ambivalent to either so @ealmloff can make the final call~~

It seems that the extra processing of the folder contents was a mistake / bad default, seems like we want to preserve contents by default and make optimization opt-in

jkelleyrtp avatar Dec 05 '24 18:12 jkelleyrtp

What is the advantage of different default optimizations for folders vs files? I would expect these two to point to the same asset:

const FOLDER: ASSET = asset!("/myfolder");
const ASSET: ASSET = asset!("/myfolder/asset.js");

rsx! {
   script { src: "{FOLDER}/asset.js" }
   script { src: ASSET }
}

If asset optimization is breaking some files, we could make it opt in instead of opt out, or just fix the broken optimizations. Either way, I think we should be consistent about the default options regardless of how you import the asset

ealmloff avatar Dec 05 '24 18:12 ealmloff

I'm mixed between both approaches as one could say that the FolderAsset is for importing something as-is, but I think file preservation should be opt-in for consistency.

DogeDark avatar Dec 14 '24 04:12 DogeDark

IMO asset-optimization ought to be opt-in in general. People wanted asset optimization will likely go looking for a setting and find it easily enough. People not wanting optimization are more likely to be surprised by it happening.

nicoburns avatar Dec 14 '24 05:12 nicoburns

What if we:

  • Left the default behavior the same (opt out of optimizations)
  • Include the with_optimize_files(bool) method.
  • We can alter the behavior if desired at a later date (non-patch release).

According to semver, an addition should be on a minor release, not a patch, but I don't believe it would be an issue to include it on a patch.

DogeDark avatar Jan 07 '25 21:01 DogeDark

What if we:

  • Left the default behavior the same (opt out of optimizations)
  • Include the with_optimize_files(bool) method.
  • We can alter the behavior if desired at a later date (non-patch release).

According to semver, an addition should be on a minor release, not a patch, but I don't believe it would be an issue to include it on a patch.

I think we should go with this direction. If you are able to make the changes today I can review + merge before EOD, hopefully unblocking the playground deployment!

jkelleyrtp avatar Jan 07 '25 21:01 jkelleyrtp

The hasher test failed and I believe it was because the AssetOptions enum was changed (which is used to calculate the hash). I set the new left to equal the right in the assertion. @ealmloff Can you confirm if this was the case & is fine?

DogeDark avatar Jan 10 '25 05:01 DogeDark

The hasher test failed and I believe it was because the AssetOptions enum was changed (which is used to calculate the hash). I set the new left to equal the right in the assertion. @ealmloff Can you confirm if this was the case & is fine?

Yes, the hash is based on the serialized form of the enum. The hash itself changing between versions isn't an issue because it always comes from the macro. However, changing the structure of AssetOptions will break deserialization of the enum with old versions of the CLI.

If you create a new project that points to this version of dioxus and try to serve it with the old version of the CLI, no assets are copied

ealmloff avatar Jan 10 '25 14:01 ealmloff

I don't see a way around breaking enum deserialization since we need to pass an identifier to preserve files somehow.

DogeDark avatar Jan 10 '25 20:01 DogeDark