Expose more Plot internals to facilitate building new mark types.

[mbostock]

In an upcoming Plot release, we should document how to implement custom mark types and expose the necessary internals to make this easier. Ideally, all of Plot’s built-in mark types are “unprivileged” in the sense that they rely exclusively on stuff that’s available publicly. That way we can feel good about the barrier to custom mark types being low.

I’m thinking we expose options.js mostly as-is, but perhaps adopt a naming convention that delineates these implementation helpers from Plot’s more commonly-needed plotting API. For example, maybe it’s renderDirectStyles, renderIndirectStyles, renderTransform, renderChannelStyles, renderOffset instead of applyDirectStyles, applyIndirectStyles, applyTransform, applyChannelStyles, offset. Or at least we do a pass on naming before exposing publicly, and have a separate section in the README (or even a different README) for custom marks.

[Fil]

Crosslinking with https://observablehq.com/d/518bef295f80fbdb and #163

[Fil]

A very useful function is valueof/field, but for the rest I don't know.

If we fork the code of a mark to change it a little, we then have to pull in all the internal functions. But, as discussed here in my experiments to create new marks I almost always found a way "around" and avoided forking. (The only hard exception might be when creating new shared scales (depends on #163).)

I think we need much more tinkering before we can identify a doctrine of what is a "plugin" and what it has access to. Maybe push this after the friends preview? (There's already a lot to play with in any case!)

[mbostock]

Two more at the top of my list:

A way to compose transforms, e.g. Plot.transform(transforms…) where each transform is a {filter, sort, transform} object. This is available internally as maybeTransform but is needed to implement custom composable transforms outside of Plot. Possibly needs a more descriptive name like Plot.composeTransform(t1, t2). Possibly the second transform should already be a transform function rather than an object, and possibly the second transform should be optional. Or possibly there should be separate methods like Plot.transform({filter, sort, transform}) and Plot.composeTransform(t1, t2) where the latter strictly takes functions.

A way to define “lazy” channels, e.g. [X, setX] = Plot.channel(source), available internally as lazyChannel and maybeLazyChannel. Maybe needs a more descriptive name like Plot.column to imply that its value must be specified as an array?

[Fil]

Closing, this feels 99% done.