extend to text and vector; document

[Fil]

• Pending issue: the default is 3 for dodge, but can be 4.5 for dot if there is a symbol channel.

[mbostock]

It seems wrong for marks to define channels they don’t use, just so they can be made available to an unrelated layout.

In the case of a constant r, this change isn’t necessary as the dodge layout already reads the r option even if the downstream mark doesn’t. If we want do do a channel (variable) r, then we’ll need a way for layouts to be able to register extra channels. But, do you think that’s required?

[mbostock]

It can be applied to any mark (that consumes x or y).

[Fil]

I want to support the same layout on text marks, so we can do this:

Maybe marking r optional in the mark itself is the wrong approach, and what we need instead is to allow the layout to ask for the (scaled) channels it wants to use? It would seem more appropriate in terms of separation of concerns.

We also don't want users to have to pass the r option differently—and maybe r is going to be the result of a bin transform—, so it shouldn't be a dodgeOption but part of the normal options.

[mbostock]

I want to support the same layout on text marks, so we can do this

As I said, your test works as-is in the mbostock/dot-dodge branch (because the dodge layout will check for the r option even if it’s ignored by the mark). And similarly in the case of a bin transform that produces an r channel, the dodge layout will consume it.

The only thing that’s missing is that if you want an r channel (i.e., variable radius) but the downstream mark doesn’t support it, then we’d need a way for the dodge layout to register that channel somehow. Maybe we could tack on a layout.channels array or something.

This discussion also makes me thing we want a way to alias channels that were computed by other marks. Like, if you dodge dots, it’s not great that we need to redo all the work to dodge text labels on top of the dots; ideally you want a way to derive the channels for the text mark from the previously-computed channels for the dot mark. Maybe we can figure out a way to do that?

[Fil]

if you want an r channel (i.e., variable radius) but the downstream mark doesn’t support it

Yes, this is what I was aiming for with these changes (the test plot I added is simpler, and it already works). I like the idea of adding a layout.channels.

The default of 3 vs 4.5 for symbols is not a huge issue, even though it would be nicer if we respected the same defaults (tracked in #711)

I realize I forgot to mention images. Beyond that, I haven't been able to make it work with any other mark yet, like ticks, rules, lines… not that it needs to be working, but I think the documentation needs to capture where a layout can be applied.

Closing for now.

[mbostock]

The default of 3 vs 4.5 for symbols is not a huge issue, even though it would be nicer if we respected the same defaults.

Yes. One possibility is that, rather than consuming the passed-in options, the layout could consult this.r when it is invoked. This way it would be able to check if the mark provides a default radius. But in the case that a mark doesn’t implement the r option, the dodge layout would presumably still need to fallback to the passed in r option.

[Fil]

An example here https://observablehq.com/@recifs/dodge-text