-
Notifications
You must be signed in to change notification settings - Fork 12k
Use one location for dataset type options/defaults #8536
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
Conversation
|
@stockiNail I'd appreciate any comments on this one, I'm not so sure if it should actually be the other way around, or should it not be changed at all. |
@kurkle I had a look and this sounds to me more consistent comparing with previous implementation. |
|
@kurkle I thought a bit more about the topic. dataset // dataset object
!
+--> options.datasets // datasets of the controller of the instantiated chart
!
+--> controllers[type].datasets // datasess default for the controller
!
+--> defaults.datasets // defaults for datasets of all controller type (maybe useless)This chain should be also "merged" (or used by proxy) quite easily I guess. Probably to maintain the datasets logic as is, you should use the implementation of this PR where the Going to this PR, I have only a doubt about custom controllers which are extending existing ones if the |
I'm not sure what benefit would
As you know, the current fallback is
The two,
Thats the idea in this PR.
The customController.defaults.datasets is automatically merged into defaults.datasets[type], in this PR, so should not be a problem. |
I fully agree with you that sounds useless. As you highlighted, the only exceptions is mixed chart.
Honestly I wasn't aware about Maybe I don't have the clear picture but the above objects could be "different" only if defaults.datasets[type}.stock = 1
defaults.controllers[type].datasets.stock = 1;
// the above statements should apply the same behavior to the chart
// and to change the first or the second statement is the sameWhat is not clear to me, why should a user change |
|
@kurkle additional thought:
If I have understood well the PR, this is new fallback:
New PR sounds to me more consistent. Does it mean that |
Yes, it would mean that. |
|
I still have some doubts. While |
In my opinion, I'm thinking loud, removing
In this case we are not consistent as well (my opinion), as you mentioned about other namespace, like Probably the best is the current one, maybe a little bit redundant. ;) |
|
I think after |
|
@etimberg I think those are (mostle at least) at |
|
Yup, that's where they are now. I just want to make sure any proposal keeps the fallback there |
|
I think the original reason for putting these options in |
|
Closing in favor of #8563 |
Combine
controllers[type].datasetsintodatasets[type], for simpler options lookup and consistent defaults/options.