Description
I'm hesitant to open this as an issue because I know the behaviour of having selection.select inherit data from corresponding nodes in the parent selection is totally deliberate. But I think it's at least worth discussing so here goes.
This side effect of select is something that confused me when I was first starting out with d3. And I regularly find myself explaining the behaviour to colleagues who are surprised by it. These explanations never seems to stop at the "what happens" but invariably continue into queries of "why would it do that"? I take this repeating pattern as a red flag that there is a rough edge in the API.
I think the confusion stems from 2 points:
- The term
selecthas strong connotations of being read-only from popular usage in SQL and other query languages. This seems to run pretty deep for people (myself included). - All other instances of
selectandselectAllin d3 besidesselection.selectare read only.
I understand that changing this would be a pretty severe backward compatibility break, but just as a thought experiment, do you see any other issues with the following?:
- Make all
select/selectAlloperations to be read only only. - Introduce
selection.update(selector)to handle the update workflow where you truly do want to propagate data across nodes. This would essentially work just likeselection.selectdoes today.
It's maybe not as seamless but there is something nice (to me) about having mutating operations be explicit even if it means sacrificing some convenience.
BTW, I posted a StackOverflow question a little while ago, but that was more targeted at techniques for working around practical issues we were hitting. It adds some relevant context to this topic, though, so here's a link.