Currently it's possible to generate random clusters (formerly known as creatures), but unlike mandalas, there's no way to _edit_ one if you decide that there's something about it that you'd like to change. This means, for instance, that if a randomly-generated cluster looks nice but needs a hat, or if it has arms you don't like, or if you find something cool in the gallery but want to remix it a bit, you will be able to make those changes.
It also isn't currently possible to randomly generate a cluster with lots of complexity; the data structure to represent a cluster is defined recursively, however, so this editing UI--however horrible this initial version is--allows for the construction of clusters of arbitrary complexity.
Note that the UX for this is currently terrible, but we can improve on it in future PRs.
This fixes#213. It is not particularly accessible, but since it (hopefully) shouldn't be displayed too often, I'm going to merge it anyways for now--better an inaccessible modal than failing silently.
This implements an _extremely_ basic Firebase-powered gallery (#26). At present it's just a list of links to creatures/manadalas that open in new tabs, without preview thumbnails. Or the ability to submit new entries. These features will be forthcoming in future PRs.
As with #215, this decouples the view logic from Firebase so we can use something else in the future if we want.
This splits up our `styles.css` file into multiple CSS files that sit alongside the TSX files that use their classes. All "generic" CSS that isn't used by any one particular component, such as our `thingy` class, is currently being put into `page.css`.
The CSS files are imported via `import` statements in their associated TSX files. As such, this fixes#164.
This also starts formatting our CSS using Prettier.
It also moves some of our `<head>` tags back into `index.html`, reverting a tiny bit of #205, to ensure that some of the metadata can be recognized by browsers, and start loading asynchronously, independently of the page's JavaScript (I see no reason why any of those elements need to change dynamically based on the app's state, so there don't seem to be any downsides to this).
Atul Varma