search

zathras / jovial_svg

Flutter library for robust, efficient rendering of SVG static images
BSD 3-Clause "New" or "Revised" License
112 stars 20 forks source link

Package the non-Flutter part as jovial_svg_no_flutter #102

Open zathras opened 3 months ago

zathras commented 3 months ago

It might make some sense to package the parts of jovial_svg that don't depend on Flutter separately, mabe as jovial_svg_no_flutter. There's one marginal use case I know of for this, but there might be others. The new package would unavoidably have a pretty big API surface area; it would need to come with a pretty strong health warning. With that said, the risk of packaging this separately (and thereby exposing more API) is much smaller now than it would have been earlier in the package's evolution.

I note that the old flutter_svg seems to have been superseded by something called vector_graphics, which has a binary format (like jovial_svg before it). I assume vector_graphics has addressed some of the other shortcomings, like not handling forward references. Anyway, vector_graphics is divided along these lines.

The impetus for this was a not-too-coherent RFE (#99) and subsequent discussion, including a rant about "architecture." But no real architectural changes are needed. Anyway, that got me to thinking about dependency management. The way the code is packaged right now interacts a little poorly with Dart's dependency system; it's easy to inadvertently introduce a dependency on Flutter's ui package into code needed by svg_to_si and avd_to_si. So from a maintainability standpoint, there's a benefit to re-packaging.

The marginal use case I know of is making a build tool that does something other than create a .si file with the binary representation. It's somewhat more convenient and slightly more elegant to do that through an API, rather than the standard technique of invoking the tool to generate a file in a temporary directory which is subsequently read.

zathras commented 3 months ago

Thinking through this a bit more, there's a problem with the dom library. That API would necessarily be a part of the jovial_svg_no_flutter package, if things were repackaged as suggested here.That's a pretty big breaking change, moving a whole public API to a different package.

If a sufficiently compelling use case for doing this re-packaging emerges, it might be worth finding a solution. But absent that, I don't plan to make any changes for now. I'll leave this issue here, as a place folks can comment, e.g. to suggest a reasonable use case. Given how things stand now, the bar for "reasonable" is relatively high, and includes "no reasonable workaround." :-)