You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see arguments to both sides. Normally I’d lean towards immutability, but there’s already the case in D3 3.x where enter.select modifies the update groups in-place, and this is quite convenient. It feels like D3 3 (and prior) is sort of in a middle ground where enter.select modifies in place but selection.data returns a new selection. It would be better to either go for full immutability, or go for mutability and look for places where we can make the API more convenient.
(Also, selection.sort is another place where selections are mutable. So for immutability, this would also need to return a new selection.)
The text was updated successfully, but these errors were encountered:
I would argue that it should modify in-place. It is incredibly convenient for charts that are full of transitions to persist your selection, and pass it a new dataset on demand. Of course, were selections to become immutable, it would not be difficult to work around, but if I had a vote, it'd be to retain the current behavior.
I can see arguments to both sides. Normally I’d lean towards immutability, but there’s already the case in D3 3.x where enter.select modifies the update groups in-place, and this is quite convenient. It feels like D3 3 (and prior) is sort of in a middle ground where enter.select modifies in place but selection.data returns a new selection. It would be better to either go for full immutability, or go for mutability and look for places where we can make the API more convenient.
(Also, selection.sort is another place where selections are mutable. So for immutability, this would also need to return a new selection.)
The text was updated successfully, but these errors were encountered: