Refactor actions to ES6
Rename Kapa & DE action creator groups & redux state top-level keys for clarity
Remove auto-add func to field in kapa
Remove unused actions and reducers from kapa queryconfigs
Replace react-addons-update with lodash _.filter and _.omit; yarn package
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
There were previously no tests around Dashboard serialization to
protobuf, so this patch adds coverage for that. Also, the `go-cmp`
package has been introduced to replace our usage of `reflect.DeepEqual`
going forward because it has better comparison features that make it
more stable across Go versions and produces nice diffs in tests when
they fail, reducing the need for debug lines and manual inspection.
"Axis" is a more consistent and appropriate name. Also, the formatting
the protobufs was all over the place, so this has been made consistent
using a first-column \t. Furthermore, a vim modeline was added to the
bottom to make it easier for editors to autoconfigure themselves to the
right format, since protobufs are not something that we edit everyday.
Also, 32-bit values have been substituted for 64-bit values in Protobuf
definitions.
Cells now have axes which represent their visualization's viewport. This
updates the Swagger documentation to reflect this.
Things to be aware of
=====================
The form of "axes" is that of a map<string,object>, which is represented
in Swagger by an "additionalProperties" key (search for "string to model
mapping" here: https://swagger.io/specification/).
The frontend would like to store viewport information for each cell so
that visualizations are zoomed to the proper extents upon rendering.
This adds a property to cells called "axes" which takes the following
shape:
```
{
"axes" : {
"y" : {
"bounds" : [
0,
2
]
},
"y2" : {
"bounds" : [
1,
3
]
}
}
}
```
Bounds specify the visible range for the axis, and are a 2-tuple of the
form [lower, upper]. Bounds are not implicitly inclusive or
exclusive--that determination is left for clients to make. Also, there
are no restrictions on the naming of axes.
Andrew Watkins
Nathan Haugo
Jared Scheib
Alex Paxton
Chris Goller
Alex Paxton
Jared Scheib
Timothy J. Raymond
Tim Raymond