## Problem
Knip reports many duplicate exports (both named and default). Besides,
we're moving away from default exports and even have an eslint rule to
enforce it on new code.
## Solution
- Cleanup those exports
- Update imports when necessary
No functional changes. If it builds, it's fine
Studio is on `react@^19.2.6`, and `useEffectEvent` shipped stable in
React 19.2 with the same signature as the userland polyfill. This drops
the local hook in `apps/studio` and `apps/www` in favor of the built-in.
**Removed:**
- `apps/studio/hooks/useStaticEffectEvent.ts`
- `apps/www/hooks/useStaticEffectEvent.ts`
- `.claude/skills/use-static-effect-event/` — skill is obsolete
**Changed:**
- 26 call sites: dropped the `useStaticEffectEvent` import, added
`useEffectEvent` to the existing `react` import, renamed call sites
- `.claude/CLAUDE.md`: `apps/studio` row updated React 18 → React 19
- `.claude/skills/vercel-composition-patterns/SKILL.md`: removed stale
"Studio uses React 18, skip these patterns" warning
## To test
- `pnpm typecheck --filter=studio` — passes locally
- `pnpm typecheck --filter=www` — passes locally
- `grep -rn "useStaticEffectEvent"` returns nothing outside
`node_modules`
- Smoke-test areas that use the hook: schema visualizer edges
(intersection check), spreadsheet import, sign-in/CLI login flows, side
panels with unsaved-changes prompts
**Out of scope:** pre-existing Tailwind lint warning on
`DefaultEdge.tsx:141` (`outline` + `outline-1` conflict) — unrelated to
this migration
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Internal event handling migrated to React’s built-in event hooks
across the Studio app; no user-facing changes.
* **Documentation**
* Clarified React 19 compatibility and noted Studio now targets React
19.
* Removed obsolete documentation for a deprecated internal hook.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46415?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Context
There's an issue with copying / exporting rows from the table editor
with the following conditions:
- Row has a column value that exceeds 10,240 and hence is truncated for
performance reasons
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/4639edbb-ece6-4028-89b6-769ac314c3f3"
/>
- User is trying to copy/export selected rows (not all rows in the
table)
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/e7c0da77-051c-4c46-af0d-f9510e0b37c4"
/>
The copy/export action will return the truncated data which is incorrect
(Should return the full data)
## Problem
This is happening as if we're only copying/exporting selected rows,
we're just using what's been loaded in the table editor to export (as
opposed to if the user is copying/exporting all rows in the table, we'd
be fetching the data from the database first before doing so)
Hence am opting to add a data hydration logic, such that if there's a
selected row that's been truncated, we'd fetch them on demand first
before copying/exporting.
There's limitations to this though - e.g if the table doesn't have a
primary key we can't do this (since we need to run a query to fetch the
data). This is already an existing behaviour when trying to load the
column value in the table editor in the grid so no issues I believe.
We'll just show this toast:
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/442637bb-4b9b-492d-b202-bbf6e5ae7512"
/>
## To test
You'll need a column with a really large value - the way I do it is to
load the data directly into the DB via TablePlus
- [ ] Verify that copying / exporting selected rows with really large
column values copies/exports all the data correctly (there shouldn't be
any truncated value)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Improved handling of truncated cell values during copy and export
operations
* **Bug Fixes**
* Copy and export operations now require an active project selection
* Fixed data export for tables without primary keys
* **Style**
* Updated grid header copy and export control layout
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46268?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Exporting all rows (in CSV, SQL, or JSON format) currently uses offset pagination, which can cause performance problems if the table is large. There is also a correctness problem if the table is being actively updated as the export happens, because the relative row offsets could shift between queries.
Now that composite filters are available in postgres-meta, we can change to using cursor pagination on the primary key (or any non-null unique keys) wherever possible. Where this is not possible, the user will be shown a confirmation dialog explaining the possible performance impact.
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Gildas Garcia
