Files
supabase__supabase/apps/studio/components/interfaces/TableGridEditor/ExposedMaterializedViewDialog.tsx
Danny White 476d4a5851 refactor(ui): drop redundant Button variant="default" props (#50161)
## What kind of change does this PR introduce?

Mechanical cleanup on top of the Button default-variant change (#50160).

## What is the current behavior?

Many callsites still pass `variant="default"` even though that is now
the component default.

## What is the new behavior?

Removes redundant static `variant="default"` from legacy `Button` and
`ButtonTooltip` callsites. Keeps explicit defaults where they document
the API:

- `button-default.tsx` and `button-sizes.tsx` demos
- `DocsButton`, which pins neutral styling at the wrapper boundary

## To test

Studio:

- [Auth → Rate
Limits](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/auth/rate-limits):
dirty the form so Cancel appears; Cancel stays neutral, Save stays green
- [Project Settings → API
Keys](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/settings/api-keys):
`DocsButton` in the header actions stays neutral

Design system:

- [Design system →
Button](https://design-system-git-dnywh-dc924ac1-supabase.vercel.app/design-system/docs/components/button):
`button-default` / `button-sizes` still show explicit default styling;
Primary (green) is restricted to the Primary section (and `asChild`)

WWW:

- [www → Brand
assets](https://zone-www-dot-com-git-dnywh-dc924ac1-supabase.vercel.app/brand-assets):
Download logo kit / Download button kit stay neutral
2026-09-11 17:05:26 +10:00

84 lines
2.6 KiB
TypeScript

import {
Button,
Dialog,
DialogContent,
DialogFooter,
DialogHeader,
DialogSection,
DialogSectionSeparator,
DialogTitle,
DialogTrigger,
} from 'ui'
import { SimpleCodeBlock } from 'ui-patterns/SimpleCodeBlock'
import { Entity } from '@/data/table-editor/table-editor-types'
interface ExposedMaterializedViewDialogProps {
table: Entity
isExposedMaterializedViewDialogOpen: boolean
setIsExposedMaterializedViewDialogOpen: (isExposedMaterializedViewDialogOpen: boolean) => void
}
export function ExposedMaterializedViewDialog({
table,
isExposedMaterializedViewDialogOpen,
setIsExposedMaterializedViewDialogOpen,
}: ExposedMaterializedViewDialogProps) {
return (
<Dialog
open={isExposedMaterializedViewDialogOpen}
onOpenChange={setIsExposedMaterializedViewDialogOpen}
>
<DialogTrigger asChild>
<Button
variant="secondary"
size="tiny"
onClick={() => setIsExposedMaterializedViewDialogOpen(true)}
>
Check possible options
</Button>
</DialogTrigger>
<DialogContent>
<DialogHeader>
<DialogTitle>Materialized view exposed via Data API</DialogTitle>
</DialogHeader>
<DialogSectionSeparator />
<DialogSection className="text-sm text-foreground-light space-y-2 prose">
<p>
Revoking <code>select</code> access from API roles <code>anon</code> and{' '}
<code>authenticated</code> mitigates the risk of exposing sensitive data to all users.
</p>
<SimpleCodeBlock>
{`REVOKE SELECT on "${table.schema}"."${table.name}"
FROM public, anon, authenticated;`}
</SimpleCodeBlock>
<p>
Note that this is a breaking change if you have code that depends on accessing the
materialized view using the Data API. To reexpose the materialized view in a safe way,
you can put a function in front of it and apply a security rule equivalent to RLS:
</p>
<SimpleCodeBlock>
{`CREATE OR REPLACE FUNCTION get_${table.name}_secure()
RETURNS SETOF "${table.schema}"."${table.name}"
LANGUAGE sql
SECURITY DEFINER
SET search_path = ''
AS $$
SELECT * FROM "${table.schema}"."${table.name}"
WHERE user_id = (SELECT auth.uid());
$$;`}
</SimpleCodeBlock>
</DialogSection>
<DialogFooter>
<div className="flex items-center justify-end space-x-2">
<Button onClick={() => setIsExposedMaterializedViewDialogOpen(false)}>
Understood
</Button>
</div>
</DialogFooter>
</DialogContent>
</Dialog>
)
}