Danny White
bfe07a5937
## What kind of change does this PR introduce?
Bug fix and design-system documentation update.
## What is the current behaviour?
Multi-select examples inconsistently hide the default trigger icon,
which makes the component default difficult to understand from the
design-system page.
The empty trigger label and selected badges also use different content
heights. Selecting or removing the first item causes the default 34px
trigger to grow or shrink slightly.
## What is the new behaviour?
- Shows the default trigger icon in every existing multi-select example
- Adds a dedicated **Without trigger icon** example for
`showIcon={false}`
- Normalises the label and badge content rows to 20px so the default
trigger remains 34px when the first item is selected or removed
- Adds regression coverage for the default trigger height classes
This follows the 34px trigger sizing introduced in
[#48696](https://github.com/supabase/supabase/pull/48696).
## To test
1. Open [Design System > Fragment Components > Multi
Select](https://design-system-git-dnywh-fixmulti-select-icon-ex-772e13-supabase.vercel.app/design-system/docs/fragments/multi-select).
2. Confirm every existing example shows the default trigger icon.
3. Confirm the new **Without trigger icon** example is the only example
without it.
4. In the first example, select and remove the first fruit. The trigger
should remain the same height throughout.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a multi-select example that hides the trigger icon.
* Added documentation and a preview for using multi-select without a
trigger icon.
* **Bug Fixes**
* Improved multi-select badge and label alignment.
* Preserved consistent trigger height when selecting the first item.
* Updated examples to display the trigger icon by default.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Supabase Design System
Design resources for building consistent user experiences at Supabase.
Getting started
First, make a copy of .env.local.example and name it env.local. Then install any required packages and start the development server:
cd apps/design-system
pnpm i
pnpm dev
The dev command generates __registry__, then runs the Next.js development server and Contentlayer together. That is the recommended workflow.
Alternative commands
You can also run the development server and content watcher separately. Generate the registry first, because dev:next and dev:content do not:
pnpm generate:registry
# Run only the Next.js development server
pnpm dev:next
# Run only the content watcher (in a separate terminal shell)
pnpm dev:content
From the repo root, pnpm dev:design-system runs the same dev script, so it also generates __registry__. If you split the watchers from the root, generate first:
pnpm --filter=design-system generate:registry
pnpm --filter=design-system dev:next
pnpm --filter=design-system dev:content
Open http://localhost:3003 in your browser to see the result.
Watching for MDX changes
The dev command watches MDX files and hot-reloads them. If you are running pnpm dev:next on its own, also run pnpm dev:content in another terminal.
Adding components
The design system references components rather than housing them. That distinction matters: everything below is about documenting components, not implementing them. Add or edit the components themselves in one of these two places:
packages/ui: basic UI componentspackages/ui-patterns: components built from libraries or frompackages/ui
After you add or remove documented components, update these source files:
config/docs.ts: list of components in the sidebarcontent/docs: the component documentationregistry/examples.ts: example componentsregistry/fragments.ts: fragment componentsregistry/charts.ts: chart componentsregistry/copy-writing.ts: copywriting examplesregistry/default/example/*: the example component implementationsregistry/default/block/*: chart block implementations, when you add a chart
Do not edit __registry__. pnpm dev, pnpm typecheck, and pnpm build generate it from the files above, and it is gitignored. If you add registry entries while the app is already running, regenerate it:
cd apps/design-system
pnpm generate:registry