d3 v7 support

[lironhl]

closes #365, This PR adds support for d3 v6!

Resources

1. selection.datum function.
2. drag.on function
3. d3 v6 changes.

[lironhl]

@danielcaldas Is the README.md treated like DOCUMENTATION.md? Should I discard my changes to README.md?

[danielcaldas]

Awesome that you tackle this one @lironhl 👍 Let's further discuss these changes, and see if we can keep backward compatibility with d3 v5

[danielcaldas]

Given the changes are minimal would that be a way of:

1. Use duck typing (or similar mechanism) to infer at runtime the d3 version that the client is using
2. Based on the version determined in step 1., use the proper APIs for d3Select and other affected integration points.

If the above is not possible, we could potentially consider the following:

1. Add a new config to graph.config.js where the user can specify the major version of d3 used.
2. Use the client-defined config.d3MajorVersion property to adapt our integration points with d3.

I would like to keep retro compatibility with d3 v5 if possible 🙏 . If we see this is too much trouble, I'll consider a major release of react-d3-graph so that we can upgrade our peer dep. on d3 to v6.

[lironhl]

@danielcaldas This is probably not that hard to do, the code will look something like this:

import { ..., event as d3V5Event } from "d3-selection";

// code

_zoomed = d3V6Event => {
    const d3Event = d3V5Event || d3V6Event;
    // code
}

1. I think supporting d3 v5 will definitely increase the code complexity in this package.

2. As you said the changes were minimal, so the users of our package won't have a hard time migrating, plus I don't think
   that the vast majority of our users, implemented a complex d3 logic, outside of our package, which means they'll only need to update their dependency in the package.json to migrate to the next react-d3-graph major release.

3. It'll take a considerable effort to support both of the d3 versions, and I don't think d3 maintainers are going to support the d3 v5 anymore (with bug fixes, features, etc), so we'll put an effort into a d3 version which may not be in the best condition over time.

I think you should consider a major release, anyway let me know what you think about what I wrote, If we'll get to the conclusion that we should support d3 v5 I'll gladly add the support for it.

[danielcaldas]

That makes total sense, I'm considering pushing this awesome change of yours in a release candidate version for react-d3-graph@3.0.0 🙂

[lironhl]

@danielcaldas I think releasing react-d3-graph@3.0.0, with this PR and my other PRs (#379 and #378), is a great choice 😆

[danielcaldas]

@lironhl Let's focus on the others first. They're not breaking changes; hence we can still release them within a 2.x version. The strategy would be to get as much stuff as possible compatible withing 2.x. Thanks for the awesome work 👏

[rhp4515]

Whats the ETA for this release @danielcaldas ?

[lironhl]

@danielcaldas @antoninklopp guys a whole new major version of d3 was released and this PR wasn't merged 😆.

Resources for this PR

--env=jsdom
rename to babel.config.js, jest doesn't recognize .babelrc for some reason.

[antoninklopp]

It looks great to me @lironhl !
@danielcaldas, I think that we should start planning for a v3 release (since you suggested that this change would be part of a v3) as a lot of people might already have moved to d3 v6 and it contains breaking changes for react-d3-graph

We might want to start with a beta?