mirror of
https://github.com/supabase/supabase.git
synced 2026-10-15 14:19:11 +03:00
Ignacio Dobronich
60a2a5e092
## Changes - Replaces plan ID-based chart gating with entitlement-based checks across all observability pages (database, auth, realtime, edge-functions) - Adds requiredPlan display field so the upsell shows the correct target plan (e.g. "Upgrade to Team" for disk throughput, not just "Upgrade") - Decouples database-charts.ts from Organization Plan, now accepts pre-computed entitlement flags instead ### Note on `requiredPlan` The entitlement system currently tells us whether a user has access, but not what plan they need to get access. `requiredPlan` is a frontend-only display hint. Ideally the backend entitlement response would include a minimumPlan field so we can remove this hardcoded mapping. For now, this is a pragmatic workaround to avoid misleading upsell copy (e.g. a Free user seeing "Upgrade" for a Team-only feature and landing on Pro). ## Testing ### Database - Head to `/project/_/observability/database` with an Org on the Free Plan and assert that the Disk throughput is gated. <img width="1402" height="682" alt="image" src="https://github.com/user-attachments/assets/b783d866-774d-44dc-88d1-797d26502f02" /> ### Auth - Head to `/project/_/observability/auth` with an Org on the Free Plan and assert that the following metrics are gated: <img width="1402" height="682" alt="image" src="https://github.com/user-attachments/assets/cb062dd7-5864-4e40-a11f-ad6be1f7fd41" /> ### Edge Functions - Head to `/project/_/observability/edge-functions` with an Org on the Free Plan and assert that the following metrics are gated: <img width="1402" height="320" alt="image" src="https://github.com/user-attachments/assets/517b5483-4575-493c-9401-2c67ac9e684c" /> ### Realtime - Head to `/project/_/observability/realtime` with an Org on the Free Plan and assert that the following metrics are gated: <img width="1402" height="722" alt="image" src="https://github.com/user-attachments/assets/0c2757a2-8482-43f4-a65c-c0dde3d878c7" />
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
const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}
export default ComponentA