Static Data and the Line Data Layer

[Frencil]

This branch implements the minimum viable product to render a line of genome-wide significance on positions panel. It does so by implementing a basic data layer of type line, as well makes use of the StaticJSON data source introduced in #53.

Line Data Layer

The line data layer uses d3's line() method to render a standard line. Layout parameters supported include style, and transition, as well as the line-specific parameter of interpolate which is passed directly through to d3's interpolate function.

Selectability is not currently implemented for the line data layer, as it's not clear what that behavior should be.

Tool tips have been implemented on this branch with a custom positioning function. What's more, to improve the "tightness" of the UI's feel, line data layers with defined tool tip content will actually render the path twice. The first pass will take styles from the layout and be visible; the second pass will render an identical invisible line on top with a predefined stroke width of 12px. This second line acts as the "hit area" for mouse events. All mouse events related to tool tips use this line instead of the rendered line but both lines are joined to the same data underneath, resulting in the ability to have thin or dotted/dashed lines that have wide, continuous mouse hit areas.

To Do

Open question which of these are in scope for this branch or could be added later.

• [x] Tool tips
  • [x] Basic mouse event binding
  • [x] Line-data-layer-specific tool tip positioning methods
• [x] Tests
  • [x] Data layer axis minimum extent logic

[MrFlick]

This static_data really doesn't feel like it belongs in the base DataLayer. Do we not have different data layer classes? I had assumed that there were sub-classes for different types like scatter plots or line plots but it seems we are just decorating instances of the base DataLayer for each of the layer types. Each layer should have the option of overriding how it gets or sets its own data if it likes, with the default behavior being to request fields from the data requester. The behavior seems like it should be specific to the specific data layer. That way those properties can have friendlier names.

It would be nice to follow a pattern with significance lines similar to the abline function in R where you can set a horizontal line value, or a vertical line value (or, less useful in this case, an intersect and slope). Having to hard code "magic" extreme values seems unfriendly.

[Frencil]

UPDATE - with #53 having merged I've ported this branch to no longer define static data in the layout and instead use the StaticJSON data source.

The line of significance is still being created by adding a data layer and tying it to a StaticJSON data source with hard-coded data to generate a line from two points. While this works it's not ideal... as previously discussed elsewhere it would probably make more sense to allow for the creation of simple graph elements like lines of significance in the layout as a property of the panel (e.g. with syntax more in the pattern of "horizontal line at y" or perhaps borrowing from R's abline function).

However we move forward on that I'd like to get a better sense of what types of lines may need to be generated independently of data like that to form a more general approach. It would also extend the scope of this branch pretty far, so I would be inclined to call this branch feature complete and tackle a better static line feature in a future iteration.