selection.merge(transition)

[curran]

I ended up investing what it might take to implement #257 and the code change seemed relatively straightforward, so I'm submitting this draft PR as a first step towards maybe implementing the feature.

I realize the implementation is not the hard part here. The hard part is weighing the pros and cons of introducing more surface area to this API.

Pros:

• Would simplify usage of .join with transitions (no need to use .call).
• Backwards compatible.
• Applies only to a "deprecated API.".

Cons:

• Adds surface area to an API that many folks already find confusing to use, which may lead to more support effort.

Closes #257

Inspired by d3-axis.

[curran]

TODO:

• Await any and all feedback
• Tests
• Docs

[Fil]

Do we also want to expose transition().merge(transition), so that merge works in all cases?
If a is a transition, should a.merge(b) be a transition?

https://github.com/d3/d3-selection#selection_merge

[mbostock]

Isn’t there already a transition.merge?

[curran]

Here's an alternative idea that enables the same simplification to usage of .join, but does not touch .merge: #286

[mbostock]

I think this approach (with my suggestion) is fine to do in addition to #286, if we want to be more lax. The general idea is we can be more lax with inputs, but we should be strict with outputs: selection.merge should always return a selection, even if we allow you to pass in a transition. Similar selection.join should always return a selection, even if we allow you to return a transition from the enter or update callback.