mirror of
https://github.com/supabase/supabase.git
synced 2026-10-15 14:19:11 +03:00
Coenen BenjaminandDanny White
853bac960e
## Problem In **Add pipeline**, the managed DuckLake configuration method (**Select Supabase projects**) lets users pick any project in their organization for the catalog and for storage. For now, managed DuckLake should only use the current project. ## Solution - Rename the option to **Use this Supabase project** and remove the **Catalog project** and **Storage project** selectors. Users still set **Metadata schema** and **Bucket**. - Remove `ducklakeCatalogProjectRef` and `ducklakeStorageProjectRef` from the form schema, default values, and validation rather than hiding them, so the form can't carry another project's ref. `buildDucklakeConfig` sets both `catalogProjectRef` and `storageProjectRef` to the current project ref, which the config builders already receive from the URL. - The bucket list and the **New bucket** dialog always target the current project. The cross-region warning is removed because it can no longer trigger. - `data/replication` (types and API payload mapping) is unchanged. It still sends `project_ref` for the catalog and storage, now always the current project. - Fix in passing: creating a bucket from the dialog now sets the field with `shouldDirty` and `shouldValidate`, so a stale "Bucket is required." error clears. - Edit mode and **Enter connection details** are unchanged. The DuckLake docs page (`apps/docs/content/guides/database/replication/pipelines/ducklake.mdx`) still describes choosing separate projects. It'll be updated in a follow-up PR that should merge after this one ships. ## Review instructions 1. Open a project, go to **Database** > **Pipelines**, select **Add pipeline**, and choose **DuckLake**. 2. Under **Configuration method**, check that the first option is **Use current Supabase project** and that there's no **Catalog project** or **Storage project** selector. 3. Open the **Bucket** list and check that it shows the current project's buckets. **New bucket** creates a private bucket in the current project. 4. Create the pipeline and check that the request sends the current project ref as both `catalog.project_ref` and `storage.project_ref`. 5. Run the unit tests: `cd apps/studio && pnpm vitest run components/interfaces/Database/Replication/DestinationPanel/DestinationForm data/replication` ## Checklist Check all before review: - [ ] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) --------- Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com>
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>
}