-
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
Fixes Bug 776 - Provide API to remove renderlets #833
Conversation
…lets which can be used for removal. Deprecates .renderlet
I meant to suggest that we don't need any API for this at all: we can use the existing d3.dispatch instance we use for other events and we can use Note that your getter only really allows dispatching (d3.dispatch doesn't give access to the actual listeners), so it might be better to offer |
Oh gotcha. I will change it to that instead. Do you want me to leave the renderlet function for compatibility sake? |
Yeah, kudos for figuring out a way to make it backward compatible! I love the idea of deprecating methods wherever we can. Maybe we could stick in a disableable |
I think that's a great idea! Maybe a dc.util.deprecate function that logs a templated message with the caller's function name. |
Alrighty, added a |
@mtraynham, even though this is almost certainly backward compatible, I'd rather merge it to develop in case there is something we missed. Am I being paranoid? |
Heh :) Well I fixed it because it was marked as v2.0, but I have no issue with v2.1. There isn't a 3.x branch, but if there was, I would have removed the Up to you @gordonwoodhull :P |
I see. I'll try to clarify the milestones, since my thinking has changed about what 2.0 means. At first I thought it was a nice round number and it should be as perfect as it can be, but since then I've come to value stability, and think only bug fixes should go in there. |
Concluded that we should set the bar where the interface can be shown to be backward-compatible, and I am quite sure that this is. Merging for beta.2 |
Looking at it more closely, renderlets don't offer anything you can't get from postRender or postRedraw. I think they only exist because those didn't used to use |
Yeah, I noticed that too. The It looks like there are quite a few places where that
When you could just call Also, almost all the events take the
Then you could just call |
How can I replace this line: |
I think you can just do: mychart.on("renderlet.barclicked", function(_chart){
_chart.selectAll("rect.bar").on("click", function(d){
timeline(1,d.x);
});
}); where |
It works! I did not know what I should use in "renderletKey". Thanks. |
Fixes Bug #776
This change adds the following methods:
This deprecates:
dc.utils.uniqueId
as the renderlet key)If you are opposed, I'm fine with removing the
.renderlets
getter function. I just thought it might be useful to trigger the renderlets at a time other thanrender
andredraw
, or specifically call a single renderlet.Edit Oop didn't see the other pull request #779 open :P I would still say we need to keep backwards compatability for
.renderlet
and this usesd3.dispatch
as @gordonwoodhull had suggested.