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).
This does the following:
* Adds logo
* Adds favicon
* Creates css directory in dist
* Creates img directory in dist
* Updates /lib/page.tsx to use helmet to incporate the logo, favicon and style.css file
* adds a new file .gitattributes to make Windows use Linux line endings per https://prettier.io/docs/en/options.html
Co-authored-by: Webaissance <git@webais.com>
This adds a new attachment point type called `wildcard` (colored `#000000` in the SVGs) which, as the name suggests, can contain _any_ kind of symbol.
Fixes#187.
This minimally fixes#143 by adding optional hills to the waves page (they default to being disabled but can be enabled via a checkbox). It also adds haze to the waves, so that they are blended with the color of the sky as they recede into the distance.
This makes us actually check TSX files with Prettier (until now we were only checking TS files).
It also re-runs Prettier, although apparently it fixes something in a TS file that was raising a warning, which I find very odd--since TS files were already being checked, I'm not sure how we didn't have a broken build...
This adds a toggle to disable gradients, fixing #140.
On the Mandala page, this changes how our permalinks are structured, but does so in a backwards-compatible way, thanks to [Avro schema evolution][1]. Now the `s` querystring argument is prefixed with a schema version, the latest being `v2`. If this prefix is missing, it's assumed to be the very first schema version, `v1`, and interpreted accordingly.
[1]: https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
Fixes#128.
A number of hook-related warnings were brought up, which this PR also fixes. Note that from now on, if there are any warnings raised by the eslint, CI will fail.
This replaces Parcel with [esbuild][].
esbuild has a number of advantages over Parcel:
* It is much, much, *much* faster. A Parcel build takes several seconds on my system, while esbuild takes 60-70 _milliseconds_.
* Parcel hard-crashes when I switch branches on Windows, esbuild doesn't.
The one disadvantage is that, as far as I can tell, esbuild doesn't support any kind of auto-reloading in the browser when you change things. IMO this isn't that big a deal and the benefits outweigh this minor inconvenience (and anyways, auto-reload has historically backfired so many times that I usually have been manually reloading the page whenever I make changes).
[esbuild]: https://esbuild.github.io/
Made the new rule the default, but its now easy to play with to adjust the exact color rule we are using. This new one pick 3 values (with a bit of randomness), picks a random hue (then picks 2 more with a small chance of taking the opposite hue), and picks a saturation level that tends to be high.
This fixes#93 by making the exported mandala filenames include the names of the symbols used in them. So for example, a mandala with circles made up of the `crown_ornate` symbol and the `heart_break` symbol will now have an exported GIF filename of `mandala-crown_ornate-heart_break.gif`.
This addresses #61 by making mandalas permalinked.
The URL to a mandala will change whenever the user stops fiddling with it for 250 ms. This means that the user can always reload the page to get a reasonably recent version of what they were creating, and they can use the browser's "back" and "next" buttons to effectively undo/redo recent changes. They can also copy the URL to share it with others.
## About the serialization format
Originally, I stored the state of the user's mandala in the URL using JSON. This had a number of drawbacks, though:
* **It was really long.** A mandala serialization was almost 1k characters, which was a very big URL, and one that some sharing platforms might even reject.
* **It wasn't type-checked in any way.** Unless I added some kind of JSON schema validation (which I didn't), the serialization was simply deserialized and assumed to be in the proper format. This could result in confusing exceptions during render time, rather than decisively exploding at deserialization time.
To resolve these limitations, and because I thought it would be fun, I decided to store the mandala state using a serialization format called [Apache Avro][]. I first read about this in Kleppmann's [Designing Data-Intensive Applications][kleppmann] and was intrigued by both its compactness (a serialized mandala is around 80-120 characters) and schema evolution properties.
It might be going a bit overboard, but again, I thought it would be fun and I wanted to play around with Avro. Also, I tried architecting things in such a way that all the Avro code is in its own file, and can easily be removed (or swapped out for another serialization format) if we decide it's dumb.
[Apache Avro]: http://avro.apache.org/
[kleppmann]: https://dataintensive.net/
## Other changes
This PR also makes a few other changes:
* Tests can now import files with JSX in them (I don't think this was required for the final state of this PR, but I figured I'd leave it in there for its almost inevitable use in the future).
* The value labels for number sliders now have a fixed width, which eliminates a weird "jitter" effect that sometimes occurred when using them.
This adds a "rotate_clockwise" property to the TOML metadata, which allows the default direction of rotation to be changed on a per-symbol basis.
Co-authored-by: Corinna Cohn <corinna.cohn@gmail.com>
This adds an "Export GIF" button _if and only if_ animation is enabled on the Mandala page.
The GIF has the same dimensions as the canvas at the time that the button was clicked.
Currently the animation is locked to 15 FPS, which I think might be the maximum rate that some platforms limit it to, but I'm not sure. We can always adjust it in the future.
This replaces the "randomize colors" and "randomize" buttons on the creature and mandala pages with a single randomizer widget that allows the user to choose whether they want to randomize the colors, symbols, or both.
By default, both colors and symbols are randomized.
Note that this is really only a temporary solution, though: ideally we'll want to provide a more powerful UI that allows users to mark _any_ parameter for randomization, e.g. via "pinning" values or somesuch.
This adds a "random color sampling" section to the right side of the debug page.
I'm hoping this will make it easier for @mittimithai to work on his random color code, since it shows a bunch of random colors (100 right now) side-by-side, rather than requiring the developer to constantly click "randomize colors" on mandala/creature to get an idea of what the color spectrum looks like, 3 colors at a time.
This adds a slider that allows the duration of the mandala animation to be changed (for #71).
In so doing, it also decouples the animation speed from the display's refresh rate.
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.
Atul Varma