dima/supabase

0 Fork 0

mirror of https://github.com/supabase/supabase.git synced 2026-10-10 20:05:06 +03:00

Files

T

Gildas Garcia 224dbb09bb chore: rename CommandMenu internal components to avoid conflicts with base shadcn ones (#45996 )

## Problem

The `ui-patterns/CommandMenu` exposes internal components that have the
same names as the base shadcn components they wrap. This create
confusion about which one to use and forces us to expose the base ones
with the `_Shadcn_` suffix.

## Solution

Rename those internal components to have `CommandMenu` in their names to
make it clearer they are meant to be used with `CommandMenu`. We will
then rename the shadcn base ones to remove the suffix.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

## Refactor
* Standardized Command Menu component naming across the design system
for improved consistency and clarity. Updated component names:
`CommandInput` → `CommandMenuInput`, `CommandList` → `CommandMenuList`,
`CommandItem` → `CommandMenuItem`, `CommandEmpty` → `CommandMenuEmpty`,
and `CommandGroup` → `CommandMenuGroup`. Updated public API exports,
internal subpath references, all examples within the registry, and
implementations across documentation, studio, and application
interfaces.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45996)

<!-- review_stack_entry_end -->

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

2026-05-20 14:05:59 +02:00

grid

fix(table-editor): wait for filter value before applying (#46113 )

2026-05-19 10:31:57 -06:00

interfaces

chore: rename CommandMenu internal components to avoid conflicts with base shadcn ones (#45996 )

2026-05-20 14:05:59 +02:00

layouts

chore: rename CommandMenu internal components to avoid conflicts with base shadcn ones (#45996 )

2026-05-20 14:05:59 +02:00

to-be-cleaned

chore: migrate old <Alert> usages to <Admonition> (#45797 )

2026-05-12 16:48:06 +02:00

Set default size for filter side bar unified logs (#46132 )

2026-05-20 18:28:14 +07:00

ui-patterns/Dialogs

style: require sorted imports in studio/components (#44408 )

2026-04-01 10:22:37 +02:00

README.md

Final replacements of ui setNotification with toast (#21885 )

2024-03-12 12:56:56 +08:00

README.md

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-cleaned folder 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.tsx as 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
const ComponentA = ({ sampleProp }: ComponentAProps) => {
  return <div>ComponentA: {sampleProp}</div>
}

export default ComponentA