diff options
| author | Owen Jacobson <owen@grimoire.ca> | 2025-07-08 01:44:46 -0400 |
|---|---|---|
| committer | Owen Jacobson <owen@grimoire.ca> | 2025-07-08 01:55:36 -0400 |
| commit | 64d16441a390e889231f2f67333d5f305b7ab878 (patch) | |
| tree | 88d686ef194eada20fc0c157e681ed72971ecc3f /docs | |
| parent | 4eb0cc56696a3805538e5ce6d380ea26e097424c (diff) | |
Set up a skeleton for swatches.
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, and are set up in a separate [group] from the rest of the UI. They do not require setup or login for simplicity's sake and because they don't _do_ anything that requires either of those things.
[group]: https://svelte.dev/docs/kit/advanced-routing#Advanced-layouts-(group)
Swatches are manually curated, for a couple of reasons:
* We lack the technical infrastructure needed to do this based on static analysis; and
* Manual curation lets us include affordances like "recommended values," that would be tricky to express as part of the type or schema for the component.
The tradeoff, however, is that swatches may fall out of step with the components they depic, if not reviewed regularly. I hope that, by making them part of the development process, this risk will be mitigated through regular use.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/developer/SUMMARY.md | 4 | ||||
| -rw-r--r-- | docs/developer/client/swatches.md | 16 |
2 files changed, 20 insertions, 0 deletions
diff --git a/docs/developer/SUMMARY.md b/docs/developer/SUMMARY.md index 6b0ce6a..71f85d1 100644 --- a/docs/developer/SUMMARY.md +++ b/docs/developer/SUMMARY.md @@ -14,6 +14,10 @@ - [Running Pilcrow locally](server/running.md) - [Debian packaging](server/debian-packaging.md) +# The client + +- [Swatches](client/swatches.md) + # Development tools - [Formatting](tools/formatting.md) diff --git a/docs/developer/client/swatches.md b/docs/developer/client/swatches.md new file mode 100644 index 0000000..df4f643 --- /dev/null +++ b/docs/developer/client/swatches.md @@ -0,0 +1,16 @@ +# Swatches + +To make it easier to experiment with the client's component framework, the client exposes "swatches" - pages demonstrating individual components in isolation. + +Swatches are available from a running client at the `/.swatch/` URL. This URL is not linked in the client; you Just Need To Know. + +## Writing Swatches + +Swatches are manually curated. When adding a component, add a swatch if you can. + +Things to consider: + +- For complex values, use a parser, so that the user reading your swatch can edit the structure as text. +- For freeform values whose meaning is significant, provide buttons to let the user rapidly enter and experiment with interesting values. +- Be thorough. Let the user experiment with values, even if you think those values may be nonsensical. +- Try to show the component _without_ supporting markup, as far as is possible. However, if a component generates markup that requires context - a table row component needs a table, for example, or a list element needs a list - then include that markup in the swatch. |