mirror of
https://github.com/supabase/supabase.git
synced 2026-10-14 05:39:11 +03:00
Danny White
ae69908aed
## Problem The pipeline creation wizard in #49243 needs to validate its destination connection before table selection. The sheet currently builds that request inside its full configuration validation. ## Solution Extract `useDestinationValidation` and use it from the sheet. It builds and sends the existing destination request, with optional pipeline settings. The sheet still validates destination and pipeline settings in parallel and retains its existing loading, error and warning handling. This foundation adds no visible changes or wizard routing. ## Review instructions Use a test project with Pipelines enabled, a publication containing tables, and working BigQuery credentials. 1. Open the [deploy preview at Database → Pipelines](https://studio-staging-git-dnywh-refactorpipeline-desti-ebcb9d-supabase.vercel.app/dashboard/project/_/database/pipelines), select your test project and click **Add pipeline**. Confirm the existing sheet opens with BigQuery selected. 2. Enter the required fields and select a publication. Use valid service-account JSON, but set **Dataset ID** to a dataset that does not exist. Click **Start pipeline**. While the request runs, expect a loading state and disabled submission. Once validation completes, expect configuration issues in the sheet, retained field values and no pipeline creation. 3. Correct the dataset ID and click **Start pipeline** again. Expect validation to recover and open the **Create and start pipeline** cost confirmation when there are no remaining issues. Click **Cancel** to avoid creating the pipeline. 4. If your test project returns warnings, confirm they appear inline and the action changes to **Start pipeline anyway**. Click it again: unchanged warnings should open the warning confirmation, and continuing should open the cost confirmation. Critical issues must still block progression.
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>
}