-
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
PoC - d3v4 support #1363
PoC - d3v4 support #1363
Conversation
Thanks @kum-deepak! This sounds like a good approach. The selection behavior has also changed a lot, since d3v3 used to automatically merge the enter selection into the modify selection. I guess maybe your compatibility layer can handle this, but when eventually removing the compatibility layer, it is still going to be tricky. Please continue to update with your progress and I'll be happy to review or help out as you go. |
Thanks for your inputs. I have been meditating for past two days on best way to handle changes to selection behavior. .enter() is currently used in 36 places. Writing a wrapper is possible but quite clumsy, the effort to test the wrapper is going to be more than direct changes (which anyway will need to be done). I understand that it is not pragmatic to maintain support for both versions in the same branch. At the same time due to nature of changes it is likely that support for D3v3 and D3v4 will need to co-exist for significant time. So, I was thinking - as far as possible - to modify in the code in a way that modified code works with D3v3 as well. So far there are following known changes
I think both of these can be created a functions that can be implemented for D3v3 and D3v4. I will commit again when I reach someplace. |
I think it's perfectly acceptable to simply move to d3v4. This was how I planned to make the port when I find time. It's true, there will be some overlap, and fixes will have to be applied separately to two branches for a while. But once we get d3v4 fully working, it should be fine to drop d3v3, since the rest of the world has already moved on. My two cents. Thank you for taking this challenge, and feel free to pursue it however you think is best. |
Thanks! I will proceed with making direct changes. That will actually make the changes simpler :) I was going through the code - the more complex changes brush() and dispatch() are used only once each. |
Your message was really timely :) |
Great! I think the scatter plot modifies the brush a little bit too, but otherwise yes that should be it. |
Fixed test cases
Have been able to get more chart types to work. One setback - the stack API has changed beyond recognition. Spent some time on that but was not able to move it. Good thing, it is a relatively isolated code in D3v3, extracted relevant part and placed in the d3-compat file. That has allowed me to go ahead. I will come back to it when other issues are under control. Next target for me is brushes. |
Awesome! Yes, having read CHANGES.md, it looks like every interface has changed somewhat, and many in fundamental ways. So grateful you are taking the time to work on this. |
Brushing itself works :) New brush APIs are simpler and is likely to yield a simpler code. I am facing a very stupid doubt, brush needs to be told the region brushing is allowed. For this I need the width and height of the chart area. How do I get that? |
That's great! You can use |
Started seeing end of the tunnel. Many examples have started working. Key pending dev work:
Examples that are not working as of now:
|
Wow! You're really getting there! Amazing work. |
Zoom and focus works now. :) |
Completely agree. Looks like we're almost there - congratulations! |
I was able to do some testing today, so I ran through all the examples. Here are the issues I found, mostly to do with initial values for elements that are entering. We don't need to fix these before putting out the alpha, but we'll definitely need to fix them, as well as using the d3v4 stack implementation, before releasing 3.0.0. I'll open issues for any that you don't fix before we merge this PR. bar charts
line charts
heat map
Transitions have many, many issues, but at least we shouldn't regress with this release. |
Thanks for your review. I have committed now draft version of upgrade guide. I now realize that other than changes to the user code for d3 changes, there are only two changes. It is possible to make those two backward compatible, will wait for your feedback. |
I think we have reached a stage where we can baseline it as a single commit, and split for work on localized/specific issues. My current (non exhaustive list):
I will describe each of these on the individual issue/PR. I will keep working one/few at a time. Will love to hear your prioritization/grouping of the above. |
It was my first experience with working with D3 - completing a month now. :) I now realize that behavior of Making the change will make the code cleaner and more manageable. However I am not sure if will make any adverse noticeable change for the user. In any case I wanted first a working version before attempting this one. In the current code sometimes, I think that when we make the above change - some subtle bugs would get fixed - which may be related to updating elements not behaving properly. Will wait for your suggestion before proceeding on this one. |
@gordonwoodhull can you please merge this pull request as a new branch (say d3v4) as a single commit. I will use that as base to continue further work. Thanks! |
Yes I'll create a 3.0 branch today. Sorry for the delay - yesterday I got bogged down thinking about whether we should be backward compatible. (It's easy enough so I think we should.) Please start opening issues for the remaining work. I'll create 3.0 milestone now. |
After having done everything, looks like we can actually be backward compatible, only two changes, which can both be extended to mimic the current API behavior. As we can move towards 3.0 we can start putting deprecation notices as suggestions to update. |
There may still remain some incompatibility around tension in interpolate/curve function. Which may impact very few users. |
Squashed from #1363 pie-charts all test cases passing with d3v4 Better alignment to build infrastructure .selectAll('anything')[0] -> .selectAll('anything').nodes() interpolate and tension semantics have changed. Updated for semantics of D3v4 .enter() Fixed test cases Discovered that more D3 functions that are used. Updated for semantics of D3v4 .enter() Updated for semantics of D3v4 .enter() and fixed test cases. All test cases for number display and row chart passing Tests passing Axis, Scales - temp Added d3-compat to examples Brushing - initial work Many examples working :) Zoom and focus working Home page charts works (issue with brushes) Fixing some of the specs X Axis brushing Brushing for Scatter Plot Brush extents and background color Brush extent specs Brushing works :) Current status Bar width corrected Area is working geoChoroplethChart Functional completeness dispatch directly implemented, compatibility code discarded. base-mixin test cases passing All specs passing All specs passing Merged D3v3-compat Minor cleanup Merge d3 compat Cleanup brush related code Updated test case Travis Inline docs - d3 documentation links and minor changes Language correction Upgrade guide draft Update copyright notice Cleanup
Sorry for the delay - I'm still not able to work much. I've created the 3.0 branch now! BTW you're not following the jshint/jscs style guides. I guess maybe you never ran plain From now on, please select |
@@ -123,9 +128,9 @@ dc.bubbleChart = function (parent, chartGroup) { | |||
// override default x axis brush from parent chart | |||
}; | |||
|
|||
_chart.redrawBrush = function () { | |||
_chart.redrawBrush = function (g, selection, doTransition) { |
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.
Whoops - looks like you added some arguments here but never pass them anywhere. I just ran into this because I wanted to add a dontSetBrush
argument. Do you remember what you were trying to do here?
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.
Specifically, it looks like you changed the signature to take the current filter/selection, but this also takes g
and doTransition
- so I guess it's a simple fix since those are unused.
if (_chart.filter() && _chart.brush().empty()) { | ||
_chart.brush().extent(_chart.filter()); | ||
} | ||
_chart.redrawBrush = function (selection) { |
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 did you remove doTransition
here? _brush.move can take a transition or a selection, just like the old brush could be applied to either a selection or transition.
It's not a big deal, just a tiny feature that makes chart resizing work better, but it makes me worry when functionality is removed with no explanation. In the future, could you please try to document the things that you disable or remove?
I guess I need to go over this PR with a fine-toothed comb before we release 3.0. We don't have full test coverage, especially where transitions are concerned - it's unclear how to test them.
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 for letting me know, I will mark in future if I remove or change any functionality.
This one, in my initial implementation, was aggravating the infinite recursion. However the current code, may not suffer from that.
I will be more comfortable if you could go through the entire change set considering it to be my first encounter with both dc and 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.
I see, you probably simplified it in order to figure out why it was recursive, and then didn't restore the feature when you were done.
No harm done. Yes, I'll read over all the changes before we release.
@gordonwoodhull how far are you through code review? Would you publish an alpha asap please? |
@Justus-Maier there are lot of changes, so it will take a while. Meanwhile you can install from 3.0 branch. Code can be considered alpha. |
Yes, as @kum-deepak says, review is taking a while. Although I've started giving them alpha numbers (we're at 2 going on 3) I am not sure when I will publish to npm & cdnjs. Hopefully later this week. (The trouble is that a lot of people will take the latest version even if it says alpha, and then complain about it. Bug reports are welcome of course!) Meanwhile, if you're using npm, you can change your dependency in package.json to: "dc": "git://github.com/dc-js/dc.js#3.0", to install directly from the github branch. |
* unexpected results. Note also that when used as a getter, this function is not chainable: it | ||
* returns the axis, not the chart, | ||
* {@link https://github.com/dc-js/dc.js/wiki/FAQ#why-does-everything-break-after-a-call-to-xaxis-or-yaxis | ||
* so attempting to call chart functions after calling `.yAxis()` will fail}. |
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.
Nice.
Reference:
#1173