diff options
| author | ojacobson <ojacobson@noreply.codeberg.org> | 2025-07-10 03:35:32 +0200 |
|---|---|---|
| committer | ojacobson <ojacobson@noreply.codeberg.org> | 2025-07-10 03:35:32 +0200 |
| commit | f74b82450aa15b3e3e47617839c297cd1d60780e (patch) | |
| tree | b9091f1fa4f73de40fb7b530798ce2d3b94aee09 /tools/build-debian | |
| parent | 223b39a57ef6ca6b8288f5a8645183c41301f411 (diff) | |
| parent | 01ed82ac4f89810161fbc3aa1cb8e4691fb8938b (diff) | |
Create swatches for Svelte components.
A swatch is a live, and ideally editable, example of an element of the service. They serve as:
* Documentation: what is this element, how do you use it, what does it do?
* Demonstration: what does this element look like?
* Manual test scaffolding: when I change this element like _so_, what happens?
Swatches are collectively available under `/.swatch/` on a running instance. They do not require setup or login for simplicity's sake and because they don't _do_ anything that requires either of those things.
Swatches are manually curated. First, we lack the technical infrastructure needed to do this based on static analysis, and second, manual curation lets us include affordances like "interesting values," that would be tricky to express as part of the type or schema for the component. The tradeoff, however, is that they will fall out of step with the components if not reviewed regularly.
Swatches are _possible_ because we've gone to efforts to avoid global data access or direct side effects (including API requests) in our components, delegating that upwards to `+page`s and `+layout`s. However, the isolation is imperfect. For example, the swatch for `Conversation`, which renders the conversation sidebar entries, causes actual attempts to boot the app as browsers pre-fetch the links on mouseover, and clicking them will take the user to the "real" application because they really are links.
Merges swatch into main.
Diffstat (limited to 'tools/build-debian')
0 files changed, 0 insertions, 0 deletions
