mirror
/
mysticsymbolic.github.io
kopia lustrzana https://github.com/mysticsymbolic/mysticsymbolic.github.io
1
0
Forkuj 0
Kod Zgłoszenia Projekty Wydania Wiki Aktywność
mysticsymbolic.github.io/.gitignore

9 wiersze
168 B
Plaintext
Czysty Zwykły widok Historia

Origination.
2021-02-03 00:26:40 +00:00
node_modules
Add more stuff.
2021-02-03 01:09:49 +00:00
.cache
Move SVG vocabulary from JSON to TS. (#59) 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/
2021-03-27 20:00:20 +00:00
lib/_svg-vocabulary-pretty-printed.json
lib/_svg-vocabulary.ts
Always permalink to Mandalas. (#99) 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.
2021-04-24 12:46:32 +00:00
lib/**/*.avsc.ts
Use esbuild instead of Parcel. (#131) 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/
2021-05-28 11:34:17 +00:00
dist/browser-main.js
dist/browser-main.js.map
Split up CSS into multiple files and use CSS imports (#206) 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).
2021-07-11 19:59:37 +00:00
dist/browser-main.css