Closed henrykeithturner closed 3 years ago
Thanks @henrykeithturner - moved to the dash-daq
repo where this would be addressed.
You're absolutely right, this is a limitation of the current API using a dict with the colors as keys - one of the values will overwrite that other.
I can see two ways to handle this:
"ranges": {"red": [[0, 10], [20, 35]], yellow: [10, 20]}
[color, range]
. This isn't as self-documenting, and has a lot of nesting that would be easy to get wrong. Also not backward-compatible unless we continue accepting both forms. But it's compact and easy to read, and inherently ordered:
"ranges": [["red", [0, 10]], ["yellow", [10, 20]], ["red", [20, 35]]]
# or, less nested but possibly more confusing
"ranges": [["red", 0, 10], ["yellow", 10, 20], ["red", 20, 35]]
Colors also don't align with the range-values if min is not equal to zero
Sorry to be a bother. I've noticed that dash daq.gauge 's color scales do not work if parsed the same color for more than one region. For example, if i have two "warning" regions which i want to be read. I've also notice that, as a workaround, if the colors are given slightly different hex codes, then it works fine.
I've attached examples below - where dial 1 is fine, dial 2 doesnt work due to the above issue and dial 3 works due to the workaround.
Thanks very much!
Harry