The pattern of using a select with a list of options and a default that
returns an error isn't bad for a one-off validation:
select myProp {
case "validOption1", "validOption2":
// no-op
default:
panic("invalid!")
}
However, we're doing this multiple times in this method, so it makes
sense to pull this out into a new method to make it clearer what's
happening.
This adds a `oneOf` function that takes some property and a variadic
list of valid options and reports whether or not that property is among
that list.
The Base and Scale options on axes can only be one of two parameters. We
weren't validating that this was the case. This patch ensures that Base
can only ever be "10" or "2", and Scale must be either "linear" or
"log".
Associated test coverage was also added.
Because we are now creating new instances of dashboards when we create a
response, it's critical to copy every element of Dashboards from the
previous to the new instance.
We were not previously copying the Type field of cells, so this was
defaulting to the empty string zero value. This patch adds "Type" to the
tests and ensures that it's properly copied
Dashboard responses had data races because multiple goroutines were
reading and modifying dashboards before sending them out on the wire.
This patch introduces immutability in the construction of the response,
so that each goroutine is working with its own set of dashboardResponse
structs.
The contract with the frontend states that bounds should come back as an
empty array instead of null when there are no bounds present. We must
explicitly specify []string{} for this to happen.
Certain aspects of the frontend requires the presence of these three
axes, so part of the contract established is that the backend will
always provide them. Since we centralize creation of
dashboardCellResponses, this is where these axes are added to all cell
responses.
Additionally, because there was previously no coverage over the
dashboard cells endpoints, a test has been added to cover the
DashboardCells method of Service.
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
Chris Goller
Tim Raymond