legends and scales #484
legends and scales #484
Conversation
accepts a function that receives the scale; if that function returns a DOM node, adds it to the figure.
… be used to recreate the scale in another plot. In particular it doesn't show the (D3) scale anymore. Instead, a convenience function Plot.scale(options) is provided, that will turn a scale *options* object into a D3 scale, ready to use in another context. (This also clears the question of mutability.)
Co-authored-by: Mike Bostock <mbostock@gmail.com>
Co-authored-by: Mike Bostock <mbostock@gmail.com>
ensure we don't compute the scale options twice always return label, clamp, type
…", "identity")
and type ("utc", "time" / "linear", "sqrt", "log"… / "categorical" / "identity")
except the following which are part of the definition of: scale.domain() // domain, nice, scale.range() // range, inset, reverse, scale.interpolate() // interpolate, clamp, round paddingInner & paddingOuter // padding
|
Is there a way to configure the positioning of the legend with respect to the plot, e.g. above or below, when using the In the linked notebook, I noticed that all of the examples like the one below had the legend appearing above the plot: |
|
No, there is no such thing for the moment. We'll probably want some configurability but we don't want to invent a new layout engine :) What you can already do, is to create the legend separately (as shown in a few of the examples). Alternatively, move it inside the figure element with d3.select?. |
|
I wanted to work on landing exposing scales first before tackling legends. Ref. #425 (comment) |
|
In the two other branches we had accumulated quite a bit of conflict with main, and I wanted to clear that. But feel free to remove anything from this PR (I think the legend part is well separated). About the issue of exposing Plot.scale(options) or not, I think that there will be a way around in any case if we expose the d3 scale: something like |
|
My preference for scales would be to just expose the materialized options (type, domain, range, etc.) with the goal of being able to take a scale constructed from one chart and propagate it to another chart; I would prefer not to expose a D3 scale instance or a scale function. We removed most of the need for that in #280 by precomputing the scaled channels, though scales still have access to the scale functions… which is a little messy. In my ideal world the implementation of scales would be hidden so that we have more flexibility in changing the implementation. Edit: Hiding the scale function/instance is not a firmly-held conviction, just my initial inclination. |
|
I'm good with this plan (including not exposing the d3 scale); it still gives enough information to re-create the scale outside of Plot if necessary. |
Fixed conflict: src/scales/quantitative.js
* coerce to the scale’s type * upgrade isoformat * document type coercion * language * changelog * update CHANGELOG * coerce invalid dates to undefined * update README * update README Co-authored-by: Philippe Rivière <fil@rezo.net>
The `src/style.css` file is not kept in the distributed ES module. Keeping it would allow to import it directly and keep it up to date when using Plot from a package manager.
* fix #379; universal dx and dy On all marks except text, dx and dy are rendered as a transform (translate) property, possibly with the 0.5px offset on high-density screens. On text marks, the dx and dy properties are used. * update README Co-authored-by: Mike Bostock <mbostock@gmail.com>
…*low*-density screens, not high-density.
(rebased #432)
build at https://observablehq.com/@fil/plot-color-legend-484
closes #23
closes #236
related: #397 #92 #425
TODO: