mirror of
https://github.com/supabase/supabase.git
synced 2026-10-10 11:55:05 +03:00
232ce7e68c
## 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? Documentation update and a small Studio copy correction. ## What is the current behavior? The Logs guide mixes unified filtering with retired SQL Explorer instructions, and the Markdown field reference loses query semantics. ## What is the new behavior? The Logs guide mixed filtering and event inspection with the retired SQL Logs Explorer workflow. It now documents the unified Logs view: default sources, filter semantics, event details, Live, sharing, bounded exports, and missing results. The log field reference uses one mapping for HTML and Markdown, preserving source IDs, query expressions, and source/query types. The Studio User-filter empty state and comments now match its Auth and API Gateway scope. ## Additional context Validation: shared-field mapping tests, guides Markdown generation, docs typecheck, targeted docs/Studio ESLint, formatting, and browser inspection of the field table. Exported Markdown includes the source IDs and usable ClickHouse expressions. Repository-wide MDX lint has existing failures; changed pages have no reported violations. Self-review: hosted Studio filtering and log ingestion were checked against the implementation, not exercised against a hosted project. The documentation assumes the unified Logs experience is the default. Stage 1 of 3. Review and merge from the bottom of the stack. Stack: #50073 → #50074 → #50075. Production docs build also passes at the stack tip after standard reference generation. Initial CI note: the spelling action failed while building its container because Debian package downloads returned 404, before checking content. The stack has no merge conflicts. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded the log field reference with ClickHouse fields, nested-field query examples, types, schema references, and capture limits. * Reworked the Logs guide with clearer instructions for filtering, event inspection, live mode, sharing, exports, retention, and missing results. * Clarified service and Postgres log behavior and updated navigation and metadata. * **Bug Fixes** * Corrected user-filtering guidance and empty-state messaging to identify Auth and API Gateway logs as supported sources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steven Eubank <eubank.steven88@gmail.com> Co-authored-by: Steven Eubank <47563310+smeubank@users.noreply.github.com>
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>
}