mirror of
https://github.com/supabase/supabase.git
synced 2026-09-10 03:51:51 +08:00
015ca3f899
The page was 2,883 words across seven H2 groups, and the intro listed seven paths. Grouping by information type on one page wasn't enough. The explainer and reference material move to their own page, and the troubleshooting group moves to troubleshooting entries, which are auto-indexed and need no navigation entry. The guide is now 1,180 words and lists three paths. - Add "Connection pooling and limits" as a child page: how pooling works, shared against dedicated poolers, pool size, connection limits, and monitoring. - Move the endpoint and IP version table up beside the connection strings it explains, rather than leaving it in a separate reference group. - Replace the troubleshooting group with two new troubleshooting entries, "Tenant or user not found" and "FATAL: Password authentication failed", and links to the existing entries for connection refused and too many connections. The existing connection-refused entry is stronger than what was here: it names the IP ban and gives the unban procedure. - Cut the pool size worked example. It said a pool size of 30 is a shared ceiling across session and transaction mode, while the Supavisor FAQ and the terminology entry both say pool size is per user, database, and mode combination. The text came from master, so the contradiction is pre-existing. Link the FAQ as the authority rather than picking a side. - Drop the duplicate pg_stat_ssl query. It already exists in connection-management and monitor-supavisor-postgres-connections, both with column tables this page lacked. Keep the one query that is unique. - Trim the application-side and server-side pooler sections, which were near-duplicates of the Supavisor FAQ down to the same three example libraries. Add the subsection to the navigation, which also adopts connecting-to-postgres/serverless-drivers. That page existed on disk and was referenced nowhere in the navigation constants. Repoint every inbound anchor, including six files in apps/www that no previous pass in this stack checked. Most of those were already broken on master.
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 — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}