mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 01:15:03 +03:00
Alaister YoungandAlaister Young
75e08577c1
Cleans up the `tableEditorApiAccessToggle` PostHog flag now that the gated UI is shipping to everyone. Follow-up to #45034 — the new project-creation checkbox makes the management UI a prerequisite, so no reason to keep it behind a flag. **Removed:** - `useDataApiGrantTogglesEnabled` hook - Old schemas-only multi-selector branch in the Data API settings page (the rich per-table / per-function toggles + default-privileges switch become the only UI) - Flag gate around the `<ApiAccessToggle>` section in the table editor side panel - Flag gates around `updateTableApiAccess` calls in the save pipeline (create / duplicate / update) - `tableEditorApiAccessToggleEnabled` telemetry property + stale JSDoc / docs references **Changed:** - `createTableApiAccessHandlerParams` no longer takes an `enabled` param — it was always `true` after removal ## To test - Integrations → Data API settings page: exposed tables, exposed functions, default-privileges toggle all render and save correctly - Table editor: creating, duplicating, and editing a table all run the expected Data API privilege updates - Project creation flow still works end-to-end (unchanged, but the submit telemetry no longer includes `tableEditorApiAccessToggleEnabled`) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * API access configuration is now always available in the table editor and PostgreSQL settings, removing previous conditional gating. * Simplified the "Automatically expose new tables and functions" interface by consolidating UI branches. * **Documentation** * Updated telemetry guidance and examples with current feature-flag references. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
61 lines
3.3 KiB
Markdown
61 lines
3.3 KiB
Markdown
---
|
|
applyTo: 'apps/studio/**,packages/common/telemetry*'
|
|
---
|
|
|
|
# Studio Telemetry Review Rules
|
|
|
|
All comments are **advisory** — suggest, do not request changes.
|
|
|
|
## When to Flag Missing Telemetry
|
|
|
|
Use judgment — not every PR needs telemetry. But **always flag** when:
|
|
|
|
1. **Changes to `packages/common/telemetry-constants.ts`** — validate event naming, property conventions, and JSDoc accuracy.
|
|
2. **PostHog feature flags without measurement.** If a PR uses `usePHFlag` or PostHog-backed hooks like `useDataApiRevokeOnCreateDefaultEnabled` to gate behavior, the flag state should be captured in a telemetry event so the rollout can be measured. Flag if the flag value isn't included in a relevant `track()` call. (Note: `useFlag` from `common` reads ConfigCat flags, not PostHog — different system, different guidance.)
|
|
3. **Feature-flagged rollouts without outcome tracking.** If a flag gates new behavior, there should be telemetry on both the flag state _and_ how users respond to the new behavior (e.g., toggle clicks, opt-in actions).
|
|
4. **Growth-oriented components adding user interactions without tracking** — onboarding flows, setup wizards, upgrade CTAs, A/B experiment variants.
|
|
|
|
When tracking is missing, comment: _"This adds a user interaction (or feature flag) that may benefit from tracking."_ Then propose an event name and `useTrack()` call.
|
|
|
|
## Feature Flag Telemetry Pattern
|
|
|
|
When capturing a PostHog flag value for telemetry, read the raw flag via `usePHFlag('flagName')` — **not** through wrapper hooks that coerce `undefined` to `false`. Use conditional spread so the property is omitted (not false) when the flag store hasn't loaded:
|
|
|
|
```typescript
|
|
const flagValue = usePHFlag<boolean>('myBooleanFlag') // for boolean flags
|
|
track('event_name', {
|
|
...(flagValue !== undefined && { myFlagEnabled: flagValue }),
|
|
})
|
|
```
|
|
|
|
For string-valued flags (e.g., experiment variants), use `usePHFlag<string>('flagName')` instead.
|
|
|
|
## Event Naming
|
|
|
|
Format: `[object]_[verb]` in snake_case.
|
|
|
|
Prefer verbs already in use in `packages/common/telemetry-constants.ts`: `opened`, `clicked`, `submitted`, `created`, `removed`, `updated`, `intended`, `evaluated`, `added`, `enabled`, `disabled`, `copied`, `exposed`, `failed`, `converted`, `closed`, `completed`, `applied`, `sent`, `moved`.
|
|
|
|
Flag: unapproved verbs (`saved`, `viewed`, `pressed`), wrong order (`click_product_card`), wrong casing (`productCardClicked`), passive view tracking on page load (exception: `_exposed` events for A/B experiments).
|
|
|
|
## Event Properties
|
|
|
|
- **camelCase** for new events; match existing convention when extending
|
|
- Self-explanatory names — flag generic (`label`, `value`, `name`, `data`)
|
|
- Check `telemetry-constants.ts` for consistency with similar events
|
|
- Never track PII
|
|
|
|
## Event Implementation
|
|
|
|
- Use `useTrack` from `lib/telemetry/track` — avoid introducing new `useSendEventMutation` usage
|
|
- New events need a TypeScript interface in `telemetry-constants.ts` with `@group Events` and `@source` JSDoc tags (add `@page` when applicable for page-specific events), added to the `TelemetryEvent` union
|
|
|
|
```typescript
|
|
import { useTrack } from 'lib/telemetry/track'
|
|
|
|
const track = useTrack()
|
|
track('product_card_clicked', { productType: 'database', planTier: 'pro' })
|
|
```
|
|
|
|
Canonical standards: `.claude/skills/telemetry-standards/SKILL.md`
|