-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Remove schemeCategory20c #1409
Remove schemeCategory20c #1409
Conversation
If you like the concept of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really clean implementation, and overall this helps clarify a lot of things.
I'll be interested to hear if you think it should be defaulted to the new colors, or if that was a miscommunication. Open to any ideas here.
The other big question is if we should offer a permanent way to set the default colors - might be helpful.
The config object and the matcher are great infrastructure improvements.
spec/helpers/standard-colors.js
Outdated
'#e41a1c', '#377eb8', '#4daf4a', | ||
'#984ea3', '#ff7f00', '#ffff33', | ||
'#a65628', '#f781bf', '#999999' | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why copy d3.schemeSet1
here? It's not going to change in d3 and if it did, it would still break all our tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I like the idea of defaultColors
in config, once we move there, we can use that to match, this variable would not be needed at all.
src/config.js
Outdated
dc.config = (function () { | ||
var _config = {}; | ||
|
||
var _useV2CompatColorScheme = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should default to true and issue the warning. This way people get backward compatibility by default, to ease their transition into the new world, but they are also informed that it's going away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
src/config.js
Outdated
|
||
/** | ||
* Set this flag to use DCv2's color scheme (d3.schemeCategory20c). | ||
* Please note this color scheme has been deprecated by D3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's been removed in d3v5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, will change!
src/config.js
Outdated
* Set this flag to use DCv2's color scheme (d3.schemeCategory20c). | ||
* Please note this color scheme has been deprecated by D3 | ||
* (https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-50) as well as DC. | ||
* @method useV2CompatColorScheme |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add an example of what you should do if you want to keep the old colors and not get the warning. Namely, you'd copy _schemeCategory20c
and apply it to each chart.
Alternately, since we are adding a level of indirection here, we could rename compatColors
to defaultColors
and make it settable and permanent, so that users could automatically have the same color set for all charts. That might be a good idea if it turns out that schemeSet1
was the wrong choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we allow setting defaultColors, we need to add in the API docs. In addition we may create an example to show how to use their color scheme.
spec/color-spec.js
Outdated
@@ -48,7 +50,8 @@ describe('dc.colorMixin', function () { | |||
}); | |||
|
|||
it('default', function () { | |||
expect(colorTest(chart, domain, test)).toMatchColors(['#9ecae1','#3182bd','#c6dbef','#6baed6','#e6550d','#3182bd']); | |||
expect(colorTest(chart, domain, test)).toMatchColors([standardColors[2], standardColors[0], | |||
standardColors[3], standardColors[1], standardColors[4], standardColors[0]]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is really opaque - is there any way to make it clear what it proves? I can't figure it out, it's not numerical or alphabetical order is it?
(We have this problem in a lot of our tests, and it's unfortunate because it means people will "fix the tests" instead of understanding why they failed.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have realized what it does, I will refactor it is a way that it does not seem so opaque :)
spec/color-spec.js
Outdated
expect(colorTest(chart, domain)).toMatchColors(['#3182bd','#6baed6','#9ecae1','#c6dbef','#e6550d']); | ||
expect(colorTest(chart, domain)) | ||
.toMatchColors([standardColors[0], standardColors[1], | ||
standardColors[2], standardColors[3], standardColors[4]]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
standardColors.slice(0, 5)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
I will make one more iteration and then we can have one more round of discussion. I want to get it right :) |
Moved to concept of If we are happy with the approach, I will add the warning message. For one time warning messages, I want to create one helper method in |
Huh, until now I thought we need the flag as well as We do need to warn when |
Yes, that indeed was my thinking - this led me to the need of warnOnce (in dc.logger). Simplifies the code :) |
…//localhost:8888/spec/
…t of `dc.config`. Made matching of colors in specs linked to variables to make cases less fragile.
…dability and resilience.
Took a stab at adding to Change log as well. :) English is my 3rd language, so you will need to review these text as well. |
Sure, I don't mind doing copy editing. It's really helpful if you put something there so it doesn't get lost. |
Completed my current round of work on this one. |
Merged in 3.0 alpha 10 |
This PR contains following:
dc.config
, which will be a single instance object. It currently holds one setting and one variable. Please see if you are ok with the concept.index.html
generation inspecs
folder, this allows to run test cases interactively by going to http://localhost:8888/spec/ - useful for interactive debugging.Charts work but they do look different :)