Files
supabase/apps/studio/components
Aaditya BhusalandAli Waseem b9d22fa237 fix(studio): stale table metadata cache invalidation after table edits (#47541)
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Bug fix

## What is the current behavior?

Fixes stale table metadata after saving edits from the table editor
drawer.

Previously, metadata-only table changes, such as column updates, primary
key/foreign key changes, table renames, or schema moves, could leave
cached table data stale. This affected the Database tables list, schema
visualizer, and reopening the edit drawer.

Fixes #47540

## What is the new behavior?

Table metadata caches are now invalidated consistently after table
create, update, delete, column delete, and queue table creation flows.

The Database tables list, schema visualizer, table editor drawer, table
definitions, constraints, foreign keys, table columns, rows, and lint
data now refresh correctly after relevant table metadata changes.

## Additional context


https://github.com/user-attachments/assets/de849710-8d7b-4d8b-af3b-5232154e996b


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

* **New Features**
* Table metadata now refreshes consistently after table creation,
updates, duplication, and deletion.

* **Bug Fixes**
* Improved synchronization for table lists, lint results, constraints,
and row counts after changes.
* Renaming or moving tables now refreshes both the previous and updated
locations.
* Column and queue changes now trigger the appropriate table metadata
updates.

* **Tests**
* Added coverage for metadata refresh behavior across edits, moves,
optional lint updates, and row counts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Ali Waseem <waseema393@gmail.com>
2026-08-25 07:43:45 -06:00
..

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 — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
  return <div>ComponentA: {sampleProp}</div>
}