Open moraleja39 opened 6 years ago
We totally understand this pain point. But in order to keep a majority of the logic as common Dart code, we had to create a separate Color class.
I've added utility methods to charts_common/lib/src/common/color.dart
to convert between the two color classes in this pull request:
https://github.com/google/charts/pull/126/files#diff-07b83f21249d0fa683b591f6fb93717e
Have a look at the color util class in the link of my previous comment
for workaround, i did like this
charts.Color.fromHex(code: '#f2f2f2')
Alternatively, you can use this function:
import 'package:charts_flutter/flutter.dart' as charts;
charts.Color getChartColor(Color color) {
return charts.Color(
r: color.red,
g: color.green,
b: color.blue,
a: color.alpha);
}
e.g.
getChartColor(Colors.red)
This basically broke my whole project. It's gave me errors in files that don't even have the package imported. I had to add a second import of the material class with "import 'package:flutter/material.dart' as mat;" to any file that used the Color class and then change every call to mat.Color. This is the worst design decision I have ever seen in a package. I don't mind you making a custom color class, but name it something different than Color. CColor, ChartColor, or ThisIsTheColorClassForChartsFlutter all would have been better. The fact that you have to have "as chart" and then "chart." on every call is absurd. I have never seen this on any other package.
I can not see any advantage of re-implementing the Color class just for this library. Given that it is a Flutter library, it seems more logical to use the Color class from the Flutter painting library.
In my use cases, I already had defined several color constants from the brand identity, and having to reinstantiate them for the charts felt rather bothersome.
Having the fromHex factory could seem handy, but I really can't see any advantage over using a base 16 int.
Any thoughts on this? Would be a non-breaking PR welcome?