Skip to content

[FR]: Support flutter_svg asset transformed files (vector_graphics_compiler) #684

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

Open
2 tasks done
Albert221 opened this issue May 8, 2025 · 3 comments · May be fixed by #685
Open
2 tasks done

[FR]: Support flutter_svg asset transformed files (vector_graphics_compiler) #684

Albert221 opened this issue May 8, 2025 · 3 comments · May be fixed by #685
Labels
contributions welcome Welcome contribute enhancement New feature or request

Comments

@Albert221
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Describe the problem

flutter_svg allows us to precompile the SVGs so that the device doesn't have to deal with SVG parsing. This is using vector_graphics_compiler package. A few Flutter versions ago, asset transformer support was also added. And vector_graphics_compiler can work as an asset transformer, which makes the compiled files be made as part of the Flutter app build process (also for flutter run, hot reload etc.) which is very convenient.

But there is one BUT, if we use precompiled vec files instead of normal text SVGs, we can't use SvgPicture.asset, but rather the SvgPicture(AssetBytesLoader(path)).

https://pub.dev/packages/flutter_svg#precompiling-and-optimizing-svgs

And flutter_gen only gives us the svg() method on SVG assets. We can of course make an extension method locally to give that ability, but in bigger codebases (or when we forget/make mistakes) we still have the .svg() available, which will result in a SVG not shown.

Describe the solution

I propose to add a configuration for the flutter_gen in pubspec.yaml to tell the package whether to generate .svg() that uses SvgPicture.asset or the other one. Or even better, more convenient to the user (as we configure asset transformers per asset file/directory and not globally), will look in the pubspec's assets and generate this or that SvgPicture invocation depending on whether it has the vector_graphics_compiler transformer in the YAML for that particular file/directory.

For reference, even the Asset transformation Flutter docs use this vector compiler as the domain example of asset transformation :)

Additional context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@Albert221 Albert221 added the enhancement New feature or request label May 8, 2025
@AlexV525
Copy link
Member

AlexV525 commented May 9, 2025

See #514 (comment).

@AlexV525 AlexV525 closed this as completed May 9, 2025
@AlexV525 AlexV525 added duplicate This issue or pull request already exists and removed enhancement New feature or request labels May 9, 2025
@Albert221
Copy link
Author

Hey @AlexV525, I've taken a look and also looked in the flutter_gen code. The comment mentioned had the issue that's no longer an issue. In 4bf4cdc, the pubspec.dart JSON data class changed type of assets from List<String> to List<Object>, that you now use to fetch the flavors map specifically for one of flutter_gen features. The same can be done to get transformers field of the particular asset object to get transformers, and if a vector_graphics_compiler exists, pass this to AssetType and use this info in svg_integration.dart to decide whether to use the SvgGenImage or SvgGenImage.vec constructor in the generated file. It looks even more doable than I anticipated at first.

Please reopen, and if you don't have time for the development, I'd be happy to contribute, just tell me.

Cheers

@AlexV525 AlexV525 reopened this May 9, 2025
@AlexV525 AlexV525 added enhancement New feature or request contributions welcome Welcome contribute and removed duplicate This issue or pull request already exists labels May 9, 2025
@AlexV525
Copy link
Member

AlexV525 commented May 9, 2025

Sure, I was occupied with business in recent months, so I was unable to produce contributions, but only doing triages and reviews.

The main idea (for me) was to make minimal changes to the core library and try to extend abilities by creating extensions. However, it was unclear how we should make extensions at the moment, so it's been postponed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributions welcome Welcome contribute enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants