mirror of
https://github.com/supabase/supabase.git
synced 2026-10-08 10:55:06 +03:00
Francesco SansalvadoreandClaude Sonnet 5
44ff5525dc
On a versioned bucket a delete is a soft delete, and the file preview panel already calls that action Archive and promises the versions stay recoverable. Nothing in the dashboard lets a user see or restore an archived file yet. This is the data layer for that, with no UI: query and mutation shapes written to the studio conventions, endpoints stubbed, returning empty. - `archived-objects-query.ts` — `ArchivedObject` / `ArchivedObjectVersion` types and `archivedObjectsQueryOptions` - `archived-object-restore-mutation.ts` — bring an archived object back - `archived-object-purge-mutation.ts` — delete it and every version, permanently - `archived-object-version-delete-mutation.ts` — remove one retained version - `archivedOverlay.utils.ts` — synthesizes the explorer rows for one folder from the archived list - `archivedVersions.utils.ts` — an archived object's history as one flat list Two prototype problems fixed rather than carried over: The prototype identified the "was current when archived" row by the sentinel `versionId === objectId`, which was load-bearing across three files and would break the moment real version ids arrived. `ArchivedObject` now carries a `currentVersion` record, so merging invents no fields and the distinction is an explicit `wasCurrentAtArchive` flag. The prototype's object had both `name` and `originalPath`, inconsistently — the path normalization existed mostly to strip a duplicated leaf folder that inconsistency produced. There is now a single `path`, and `getArchivedSegments` is the only function that interprets it, so a different API shape is a one-place change. Also drops `deletedBy` and `expiresAt`, which the prototype never rendered. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.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>
}