Conversation
|
TODO:
|
curran
changed the title
Fil
left a comment
Fil
left a comment
There was a problem hiding this comment.
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?
|
Isn’t there already a transition.merge? |
Co-authored-by: Philippe Rivière <[email protected]>
|
Here's an alternative idea that enables the same simplification to usage of |
|
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. |
Co-authored-by: Mike Bostock <[email protected]>
3 participants
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:
.joinwith transitions (no need to use.call).Cons:
Closes #257
Inspired by d3-axis.