the default sorting of Plot.dot didn't work with Plot.hexbin #889
Conversation
… because options.r was undefined when we initialized the mark (i.e. before the initializer is called). In that case we now pass a channel (an empty array), allowing Plot.dot to set up the default sort. The channel will be overridden by the initializer.
There was a problem hiding this comment.
Actually, I’m not sure whether I prefer this or #891.
Since initializers run after mark construction, there’s no longer a guarantee that the mark will know which channels will be available on render at the time the mark constructor is called. So either we say it should be the responsibility of the initializer to indicate that the channels will be available (which this PR does only for the r channel on the hexbin transform, but not in general); or we say that marks shouldn’t assume to know which channels will be available. #891 takes the latter approach which feels a little bit more robust in this regard, even though the constructor is arguably “confused” about what will happen on render.
|
I think I prefer #891 because this felt a bit like a hack. However, if we wanted to have the transform "inform" the mark that it might create a new channel, we could introduce a specific symbol "delayed channel" rather than this []. There might be more use cases later. |
|
Sounds good. Closing in favor of #891 then. |
… because options.r was undefined when we initialized the mark (i.e. before the initializer is called). In that case we now pass a channel (an empty array), allowing Plot.dot to set up the default sort. The channel will be overridden by the initializer.
Sorry I didn't catch this when reviewing #801