Manganis: Add Flag To Disable Folder Optimization
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.
~~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
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
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.
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.
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.
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!
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?
The hasher test failed and I believe it was because the
AssetOptionsenum 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
I don't see a way around breaking enum deserialization since we need to pass an identifier to preserve files somehow.