Axis options

[GraceGSy]

Changes in this PR:

Axis options

• Styling options added for axis main line, labels, title and ticks
• Positioning options for axis using hjust/vjust or x, w/y, h (in screen pixels) or x1, x2/y1, y2 (in screen pixels)
• An extra tick can be added at the origin of each axis for non-categorical variables, label for this extra tick can be toggled
• Minor adjustment to defaultFormat.js so that all output is in type String

Nested axes

• Axes can now be nested in subsections, see Multiline in sandbox

Axis docs

• Updated axis docs

Feedback needed

• In order to fix the height/width of the x/y axes to 100px, a recursive function getParents() is used to implement an inverse this.$$transform
• This may not be the best/most efficient method of converting screen pixels to local coordinates
• Also: the extra tick comes with a label, that may sometimes be oddly formatted (see scatterplot). This implies that the user will have to manually set the formatting if the label turns out weird. Should we just remove the label for the extra tick at origin?

[GraceGSy]

Thanks for the feedback! Just to clarify the points raised:

• I'm using the getParents() function to compute this._parentNodes and then using that for the getLocalX and getLocalY functions. They're used in individual axis components, such as tickMin, tickMax, or converting this.x1 into local coordinates. In general, the width/height dimensions are entered using the inherited Rectangular props (so x1, x2, y1, y2 etc...). But I definitely agree that getParents() is doing extra work, so I don't really like it as a solution. Adding String processing logic to Rectangular sounds much better.

[Also to be honest, there is no real reason the axis needs to be any particular width/height since tick sizes and stroke widths are all customisable. I'm just arbitrarily using 100px to set the size of the section enclosing the axis. Maybe this isn't the best implementation but I wanted to make it easier to calculate local coordinates for tick sizes in some cases.]

• I think I must have missed some vgg-points when merging. Which ones are still showing up as vgg-symbol? B/c I do agree that using radius with points is more intuitive, so if anything is still using vgg-symbol that would be unintentional...

• Yeah, an extra prop for first tick label sounds good

[luucvanderzee]

Wait, if the axis is just inheriting from the section that it is in, why does the section need to be 100px? I don't really understand this point