[enhancement] Expose Mark's data properties like domain

[dgrcode]

Feature Request

I'd like to be able to get properties from my data before the plot is created, so I can use them during plot creation.

For simplicity, let's say I want to increase my Y domain so it has 10 extra units on each side. I'm thinking it would look something like the following:

const lineMark = Plot.line(values)
const [yDomMin, yDomMax] = lineMark.scale('y').domain

const chart = Plot.plot({
  y: {
    domain: [yDomMin - 10, yDomMax + 10] // for example
  },
  marks: [lineMark]
})

Right now I'd have to do some math, that I imagine will be redone during plot creation.

Why

I'll describe the use case in particular that has triggered this request, since I might be missing something that could allow me to do it with the current state of the library.

I want to be able to find the distance between my domain in y, and add an extra 10% of domain on each side. Sort of like padding the domain.

The reason is that I feel the line is the beginning of the data when the line starts exactly on the bottom-left corner. Adding the padding makes me feel I can scroll sideways to see previous data. Not sure if it makes sense, but that's the way I see it ¯\_(ツ)_/¯

EDIT: Adding an example of what I mean by "padding the domain" in a chart
|

Note how the line is separated vertically from the edges of the chart by adding more empty chart –vs adding empty space–.

Current Workaround

The current solution I've found is to use d3.extent, but that's about extra 12.6 kb (gzipped) that I imagine is already bundled with plot.

Additional workarounds that I've tried:

• Create another plot as "draft" and get the data I need from there. I went a different way because I feel it's too much to create a brand new plot just for this. The code looked more or less like the following:

  const draftChart = Plot.marks(Plot.line(values)).plot()
  const yExtent = draftChart.scale('y').domain
  // the rest of the code would look just as the code using d3.extent

• Try to mutate chart.scale('y').domain after plot creation. This didn't change anything. The object property was updated, but I imagine the plot itself was created before the mutation, so it didn't have any effect. Maybe a plot.update() method would be handy here, which could be related to updating in place? #1022.

[Fil]

I wonder if inset could be the right answer for this use case? It's in pixels, so if the chart is 400 pixels high and you want something like a 10% padding on top and bottom, try:

Plot.plot({ y: { inset: 40 }, marks: [Plot.lineY(data)] })

You could also try to add the nice: true option to the y scale, independently or in combination with the preceding setting; it might also help avoid this “bottom-left corner” issue.

chart.scale('y') exposes a copy of the computed scale, so you can create a new chart with a consistent scale—it's not meant for updating a chart.

[dgrcode]

Thanks for your reply! :)

I'm already using nice, which I think gives the charts a nice touch (pun intended 😄).

I've tried inset and it's not quite was I was looking for. I'm adding a couple of screenshots below to show what I meant (now I'm thinking I should've added them in my original post 😅):

	inset	manually padding the domain
bottom-left effect
not starting at the corner

More than how to achieve the exact effect I was looking for here –padding the domain–, I was thinking it would be nice to be able to extract some properties from the marks themselves. I've seen Mike's reply below, which raises good points about those properties.

[mbostock]

I don’t think the proposed API would work well because it only considers a single mark (the line mark); in practice most Plots include multiple marks as well as scale options which collectively affect the definition of the y-scale domain. Therefore it would be almost intractable to pull out a single mark (or a subset of the plot), extract the y-scale definition, and then construct a new plot with an almost-the-same-but-not-quite definition of the y-scale.

Like @Fil said, the inset and nice scale options are both attractive here. The issue with the inset option is that it is in screen space (i.e., range) rather than data space (i.e., domain). I could imagine another scale option that is for padding the domain in data space, although that would only be possible for quantitative scales (since you can’t add or subtract ordinal or categorical values). I could also see it being nice to have a fractional inset, where rather than specifying the inset in pixels, you specify it as some proportion of the available range (e.g., the inner width or height of the plot).

[dgrcode]

Thanks for your reply! 😃

You're right about multiple marks. I hadn't thought in depth about various scenarios. I've seen there's the Plot.marks([...]) method, which could solve the multi-mark scenario.

I was thinking some way of extracting properties of the data, that I imagine are already going to be computed anyways. True that having that info from the marks would be missing on the modifications added by other channels.

But I totally see how this might be only used for very obscure scenarios and therefore not worth implementing.

Regarding the possible scale option, I like the idea. There you mention quantitative scales, ordinal, and categorigal values. I think I know what they mean (continuous data vs "bucketed" data?), but would love to learn more. Do you have any recommended resource to read about types of data and representations?

I also want to copy here some screenshots from my reply to Fil to better show what I mean with "padding the domain", which I think can be a bit confusing:

inset	manually padding the domain

Note how the inset is separating the chart from the x-axis and label with empty space, vs "padding the domain" adds extra chart instead of empty space.

As far as I understood, with the possible scale options you mean different ways to define that inset, either in pixels, domain units, or fractionally. I think that'd be a good addition giving people more flexibility to add the inset. Although that's slightly different from my original use case.

By the way, if you'd like to add those scale options, I'd be happy to give it a try in a PR.