Restructure the dashboards to leverage mosaicLayout
#18
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This layout is more cumbersome because of the requirement to explicitly lay things out, however, this change introduces a number of helper modules to make this a bit more tolerable.
At a high-level, "sections" (our own intermediate concept) produce groupings of tiles laid out relative to
(0, 0)
with a width ofmodule.width.size
(see below).The modules in
./dashboard/sections
group our "widgets" into arrangements of "tiles" (e.g. logs, http, resources) with several special helper modules:width
: This module exists to define a global constant for the dashboard width,collapsible
: This wraps a list of tiles in a "collapsible" region with a title (it automagically figures out the bounding box, to avoid human error here),layout
: This takes a list of "sections" (defined above) and rebases them so that theyPos
of each section starts after the preceding section.This also incorporates a change to give our networking module's DNS constructs unique names, so that we can provision multiple distinct private networks (I hit this creating a small example to test with, and it conflicted with my dev environment).