createAxesMixin uses a boolean type where a literal would be more appropriate, however this is not yet supported by TypeScript.

See (at time of writing): b765f27

Data visualization for Dojo 2 fits in with the widget system. This means being able to declaratively render charts using the app factory, pulling data from stores, being able to mix in behavior, and so forth.

It also utilizes TypeScript. This allows charts to be created that have specific expectations on their input data. Rather than requiring users to compute the numbers needed to render a chart, charts can be plotted based on the objects already used elsewhere in the application.

Dojo 2 provides extensible chart types. Users can then develop chart widgets in accordance with their style guide and data requirements, such that it can be wired into an application without any further configuration.

Initially charts will be rendered as SVG, however the methods that produce the VNodes must be separate from those that compute the plot points. This will make it easier to extend charts using AOP, as well as target different renderings.

As much as possible charts should be styled using CSS, using both semantic and customizable class names. Only where necessary for correct rendering, or because CSS does not have sufficient browser support, should styling options be configured when building charts.

Configuration itself must be flexible, including pulling from stores, taking options, and providing it when creating subclasses.

Charts must be reactive, responding to state changes or subscribing to observables. Indeed observables are used to perform the computations necessary for plotting.

Column charts don't support a minimum domain value that's larger than 0, or a maximum domain value that's less than zero. Other chart types will have similar constraints.

We need to decide how these domain values are handled. Perhaps an error should be raised? Or should the domain be clamped to an allowed value?

Note that the domain can be changed at runtime so raising an error is not necessarily informative.

The distrubition build is broken:

Using tsc v2.0.3
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'ComposeFactory' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-compose/compose" but cannot be named.
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'Destroyable' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-compose/mixins/createDestroyable" but cannot be named.
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'EventedListener' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-compose/mixins/createEvented" but cannot be named.
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'EventedMixin' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-compose/mixins/createEvented" but cannot be named.
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'Handle' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-core/interfaces" but cannot be named.
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'StatefulMixin' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-compose/mixins/createStateful" but cannot be named.
src/render/mixins/createSvgRootMixin.ts(61,7): error TS4023: Exported variable 'createSvgRootMixin' has or is using name 'TargettedEventObject' from external module "/Users/kitsonk/github/dataviz/node_modules/dojo-compose/mixins/createEvented" but cannot be named.

In a stacked column chart, if the stack contains negative and positive columns, the stackSpacing does not apply between the columns immediately below and above the zero line.

We could consider taking half the spacing is away from each column. Note though that the zero line is considered to be 1px high, and this may look strange when other stacks in the same chart contain only negative or positive columns.

The various axes types will render duplicate grid lines and ticks at the zeroth point. If grid lines / ticks have already been rendered at the zeroth point, any new render positions should be compared to avoid rendering duplicate lines and ticks.

The relative-values, sum and max data operators currently do not handle infinite values. They should do something sensible so charts don't suffer terrible breakage when such unexpected values are used.

The createAxesMixin is far from complete:

• It assumes datum values are >= 0 for horizontal axes (no negative values), but <= is supported for vertical axes
• Axes configuration cannot be provided through the widget state. This would also require label selectors to be defined on the prototype since they can't be serialized into the state. Perhaps as topInputLabelSelector, etc
• Axes configuration cannot be provided through the prototype. This is necessary to create widgets with a default configuration
• It's unclear how a default configuration would be extended through options and/or state
• Certain configuration may be default for all enabled axes (e.g. ticks). Would be cool not to have to repeat that
• Chart dimensions are not adjusted if exceeded by grid lines
• No support for "mini ticks". These should probably be restricted to range based axes, where the step size must be a multiple of the mini tick interval
• Consider center (vertical) and middle (horizontal) axes for charts with negative values
• Our targeted IE versions may not support dominant-baseline. If we know the line-height we may be able to polyfill the currently limited set of allowed values, or maybe we need to support a perpendicularOffset option and remove dominantBaseline
• We may need perpendicularOffset anyhow (e.g. for the bottom axis it would move the label down, for the left axis it would move it further left)
• Axes tend to draw duplicate ticks and grid lines for the "zero" position