mirror of
https://github.com/supabase/supabase.git
synced 2026-10-14 13:49:09 +03:00
Danny White
6a4cbefbcf
## What kind of change does this PR introduce? Bug fix and shared UI primitive. ## What is the current behaviour? In **Database > Replication > Add destination**, the searchable **Publication** field uses a double chevron and button styling. It looks inconsistent beside the **Initial sync** select, which uses a single chevron and the standard select surface. The shared multi-select trigger uses the same inconsistent double chevron. These differences are easy to repeat because searchable comboboxes do not have a dedicated trigger that shares the select styling. ## What is the new behaviour? - Adds `ComboboxTrigger` with the same shared styling as `SelectTrigger` - Uses a fixed single down chevron so combobox and select triggers cannot drift - Migrates the Studio **Database > Replication > Add destination > Publication** field to `ComboboxTrigger` - Updates `MultiSelectorTrigger` to replace `ChevronsUpDown` with the same fixed `ChevronDown`, including **Connect > MCP > Feature groups** in Studio - Updates the canonical design-system combobox examples - Leaves `Button` unchanged, so adopting combobox styling is explicit | Before | After | | --- | --- | | <img width="1256" height="448" alt="CleanShot 2026-09-09 at 10 21 32@2x" src="https://github.com/user-attachments/assets/bb7a6056-0b4e-4cb4-8dce-e92fa4f5afe7" /> | <img width="1256" height="448" alt="CleanShot 2026-09-09 at 10 21 11@2x" src="https://github.com/user-attachments/assets/860a06b9-617d-4d94-ac98-944316e9fdc3" /> | | <img width="1210" height="520" alt="CleanShot 2026-09-09 at 10 58 28@2x" src="https://github.com/user-attachments/assets/e916d3a2-6a75-40eb-965a-56e0694ba447" /> | <img width="1210" height="520" alt="CleanShot 2026-09-09 at 10 57 57@2x" src="https://github.com/user-attachments/assets/c5f1b8ff-8083-47b8-8242-59116d085c00" /> | ## Left for incremental migration These existing Studio comboboxes still use bespoke button triggers and will move to `ComboboxTrigger` in focused follow-up changes: - **Database > Backups > Point in time > Timezone** - **Authentication > Third-party auth > AWS region** - **Account > Preferences > Timezone** - Shared schema and function selectors See https://github.com/supabase/supabase/pull/50157. The organisation and project switchers in the top navigation are intentionally out of scope. They are context switchers rather than form-field comboboxes. ## To test ### Studio callsites On the [Studio preview](https://studio-staging-git-dnywh-featcombobox-trigger-supabase.vercel.app): 1. Open **Database > Replication > Add destination**. 2. Compare **Publication** with **Initial sync**. Both should use a single down chevron and the same closed-field surface, border, sizing, and hover treatment. 3. Open **Publication**, search for an option, and select it. The popover should close and the selected publication should be shown. 4. Open **Connect** from the project header, select **MCP**, and check **Feature groups**. Its multi-select trigger should use a single down chevron. ### Design system 1. Check the [combobox examples](https://design-system-git-dnywh-featcombobox-trigger-supabase.vercel.app/design-system/docs/components/combobox). 2. Check the [multi-select examples](https://design-system-git-dnywh-featcombobox-trigger-supabase.vercel.app/design-system/docs/fragments/multi-select). 3. Both trigger types should use a single down chevron.
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}