This improves the layout of all our pages to look more like the mandala page.
Additionally, some form widgets now have better layout, and the header takes up less vertical space.
At an implementation level, the component hierarchy of pages has been inverted to make this kind of layout easier. Now fully laid-out pages are contained within `<Page>` components that are at the top of the component hierarchy, and which are defined by each specific page (mandala, creature, vocabulary, etc).
I had to do a few architectural things to avoid circular imports, though; most notably, this involved the creation of a new React context called a `PageContext`.
It uses CSS grid, which should be pretty well-supported amongst recent browsers.
This fixes#67 by making the background color selection/randomization code more DRY via the addition of a new `SvgCompositionContext` and a `CompositionContextWidget`.
It also documents the `SvgSymbolContext` type, and moves the "randomize colors" button closer to the actual colors.
The random colors are currently terrible! Maneesh will help us make them better. :)
Also, there is some annoying code duplication going on here between the creature and mandala pages, but I really wanted to add the button to both and also want to eat dinner soon, so I am filing #67 and saving the refactoring for later.
The key phrase here is **less terrible**, as opposed to **good**.
Right now if the mandala gets too big for the page, it will just overflow and the remainder won't be visible (not even via scrolling). This is intentional, though, as per @ninapaley's suggestion:
> I'm hoping you can change the way the image keeps resizing its canvas, and keeps justifying left.
> Maybe have an oversize canvas with the ring pinned to the center, and all the adjustment sliders
> on the right? Then they won't disappear if the canvas is too big. Also! I have an idea for an
> animated cycle that would require the symbols to eventually outgrow the canvas area and disappear.
I'm not super happy with this CSS, it doesn't feel terribly maintainable. Ah well, maybe we can improve it later.
Ugh, we need to write out a TypeScript file instead of importing the JSON directly because otherwise the TS compiler will spend an inordinate amount of time doing type inference, which massively slows down type-checking (especially in IDEs and such).
The TS file actually uses `JSON.parse` on a stringified version of the JSON instead of just inlining the JSON itself because [apparently it's much faster][1].
[1]: https://www.bram.us/2019/11/25/faster-javascript-apps-with-json-parse/
Nina Paley