gjmcn / teapot Goto Github PK

See docs for current limitations.

Any plot element that is a potential target for interaction should be easy to select.

Add support for common types of interaction that are not easily added using updates alone. In particular:

• tooltip

• hover/click on legend to toggle marks — possibly with option to hide all others

• show vertical and horizontal lines from cursor to axes

• brushing

• others?

The Observable notebook allows people to interact with the examples, but is not good for navigation. Either split into multiple notebooks, embed notebook in standard webpage with sidebar/navbar, or move the docs to a standard site.

For (non-data) array and object valued options, check that we either extract values from these to store in the plot object or copy the array/object — so that subsequent changes to the array/object will not change subsequent plots.

(Leave data as is — changes are reflected in subsequent plots).

We can create e.g. a boxplot by combining marks of different types. The approach can then be wrapped in a function for reuse. Is this enough, or should there be a standard way to register a boxplot as a new mark type so can write tp.boxplot( ... where use the standard channels as well as boxplot specific channels and options. This is not trivial since Teapot must know how boxplots contribute to limits, where to put notes etc.

Consider:

• path: takes a path string (useful for maps). Also allow using x and y instead of a path string? — are there use cases?

• hull: use d3-polygon.

• ellipse: use SVG <ellipse> and include rotate channel.

Why only allow state and data methods to be called once. However, a plot object only looks at the dataset and state when we call the plot method? — so changing them between plot calls is safe?

Currently everything in one large file due to Zap compiler issue #2 making bundle size large.

When draw marks, add a _tp property to each mark element; this object will have a method for every channel the mark uses. Pass a method the new channel value (in plot space) and the method will convert it to the required value and modify the element. Use these methods when initially draw the marks, but also to update a mark, e.g.

elm._tp.x(70).y(5);

Elements can be selected based on the attributes added by the class and name channels. Allow passing a function as the new value so that the actual value can depend on data attached to the element — or anything else.

Notes/questions:

• How handle dependencies between channels - e.g. when set new x value, the converted x value depends on the current xOffset, but what if this itself has been changed programmatically? Do we need to track changes to channels? Do we only allow some channels to be changed?

• Should transitions be included?

• Notes must change accordingly when the corresponding mark elements change.

• The suggested approach is very different to creating a plot. Could it be similar? E.g. continue to use the plot object, but when call the mark method, simply changes the values of existing elements?

• The limits and computed space will not be aware of any changes to marks — so the original space and limits must be appropriate for changes that will/can happen? - e.g. the full range of values that can be reached via interaction.

See: State of JS and CSS plots

Currently validate data (to some extent at least), but in most cases, not options. Should check:

• option names: will prevent confusion where option does nothing because misspelt, or because passed mark option as top-level option or vice versa.

• option values: less trivial, focus on most important.

Modify rollup config to get sourcemaps from minified bundle pointing to Zap code.

For path marks, we use scale in the transform attribute, so need to use non-scaling-stroke for the vector-effect attribute. However, this means that when we use the fit: 'preserve' option, the path strokes do not scale like other strokes.

We currently facet by grouping the data first then creating separate plots or subplots. Should there be a dedicated, simpler way to facet? E.g. a facet channel, or a tp.facet helper function that does the grouping and iteration?

Similarly, we group and then use tp.each to add multiple lines/bands to a plot, but should there be a more direct way?

Can use fit: 'preserve' to fit plot to container width while preserving aspect ratio. Add more fit values? E.g. so when container width changes, only the plot width changes — the height, font sizes etc. do not.

This at least seems to be the case when listen is state-based and channel is falsy. Should only be be truthy/falsy that matters — and this is what code seems to use?!