It really should though... because currently this leads to .svg images being reloaded on every build.
Every time build() runs (which happens on any state change — dark mode toggle, text scale change, navigation, etc.), this line executes:
DarkModeColorMapper(ref.watch(darkModeProvider))
That creates a new instance. Dart's default == is identity (identical()), so even DarkModeColorMapper(true) == DarkModeColorMapper(true) is false — they're different objects in memory.
flutter_svg's SvgPicture.asset uses the colorMapper parameter as part of its cache key. When the new mapper isn't == to the old one, flutter_svg treats it as a different configuration and re-parses/re-fetches the SVG asset — hence the repeated GET requests on every rebuild.
With ==/hashCode overridden, two DarkModeColorMapper instances with the same _darkMode value are considered equal, so flutter_svg hits its cache and skips the fetch.
It really should though... because currently this leads to .svg images being reloaded on every build.
Every time build() runs (which happens on any state change — dark mode toggle, text scale change, navigation, etc.), this line executes:
DarkModeColorMapper(ref.watch(darkModeProvider))That creates a new instance. Dart's default
==is identity (identical()), so evenDarkModeColorMapper(true) == DarkModeColorMapper(true)is false — they're different objects in memory.flutter_svg'sSvgPicture.assetuses thecolorMapperparameter as part of its cache key. When the new mapper isn't==to the old one,flutter_svgtreats it as a different configuration and re-parses/re-fetches the SVG asset — hence the repeated GET requests on every rebuild.With
==/hashCodeoverridden, twoDarkModeColorMapperinstances with the same_darkModevalue are considered equal, soflutter_svghits its cache and skips the fetch.