mirror of
https://github.com/supabase/supabase.git
synced 2026-09-07 02:20:52 +08:00
d5436ae826
## 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? Feature (+ a small refactor and a docs/convention note). PR 4 of the stacked SQL-editor query-source series (Database vs Logs). ## What is the current behavior? The SQL editor has no representation of a logs query's time range: `querySource.ts` only knows how to map a snippet type to a source (`getSnippetSource`), and session state (`sql-editor-session-state.ts`) tracks results and the row limit but not a per-snippet time range. The Logs date picker's pure range helpers (`parseCustomInput`, `generateDynamicHelper`, the `Unit` type) are trapped inside the `Logs.DatePickers.tsx` React component. ## What is the new behavior? - **Logs time-range domain** in `querySource.ts`: branded `IsoDateTimeString` + `isoDateTimeString()`, `RelativeTimeUnit`, a `LogDateRange` discriminated union (relative/absolute), `DEFAULT_LOG_DATE_RANGE`, a single date-picker parser (`datePickerValueToLogDateRange` / `logDateRangeToDatePickerValue` — handles the five presets *and* dynamic `2h`/`30m` helpers; `calcTo === ''` means "now"; unparseable helpers degrade to absolute), and `resolveLogRunRange` which re-resolves relative ranges against `now` at run time (reusing the existing `ResolvedLogDateRange` shape). - **Session state**: per-snippet `logRange` + `setLogRange` — session-only, never written to snippet content, so it works on read-only shared snippets and is cleaned up in `clearForSnippet`. - **Refactor**: extracted the picker's framework-free helpers into a new pure `Logs.datePickerHelpers.ts`; the logs domain now shares the `Unit` type and reuses `generateDynamicHelper` instead of duplicating them. Importers point at the new module directly (no re-export shim). Hardened the amount parse against `NaN`. - **Full unit coverage** in `querySource.test.ts`. Recorded the no-shim refactoring convention in the `studio-best-practices` skill. Verification: `pnpm typecheck` clean, lint ratchet improved, 43 tests pass (querySource + Logs.Datepickers), Prettier clean. ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added robust Logs date-range modeling with support for relative (e.g., last N units) and absolute time periods. - SQL Editor sessions now remember log date ranges per snippet. - **Bug Fixes** - Safer handling of invalid or missing date inputs, with sensible fallback to default/current time. - **Tests** - Added/expanded automated coverage for date-range conversion, helper parsing, and resolution behavior. - **Refactor** - Centralized date-picker helper utilities for reuse across the Logs and SQL query experience. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
74 lines
2.8 KiB
TypeScript
74 lines
2.8 KiB
TypeScript
import { proxy, ref, snapshot, useSnapshot } from 'valtio'
|
|
|
|
import type { LogDateRange } from '@/components/interfaces/SQLEditor/querySource'
|
|
|
|
/**
|
|
* Ephemeral, per-session SQL editor state that is NOT persisted: query results,
|
|
* the row limit, and the per-snippet logs time range. Kept separate from the
|
|
* snippet/folder store (which deals with persistence) because none of this is
|
|
* saved — it lives only for the current editing session.
|
|
*/
|
|
export const sqlEditorSessionState = proxy({
|
|
/**
|
|
* Query results, if any, keyed by snippet id. An array per id as we once
|
|
* experimented with a notebook-style multi-result UI; the shape is kept since
|
|
* a single query with multiple statements can return multiple results.
|
|
*/
|
|
results: {} as {
|
|
[snippetId: string]: {
|
|
rows: any[]
|
|
error?: any
|
|
autoLimit?: number
|
|
}[]
|
|
},
|
|
|
|
/**
|
|
* UI-imposed limit for the number of rows a query can return (a safeguard
|
|
* against accidentally taking down the database with a huge SELECT). Related
|
|
* to `autoLimit` in `results`; see `applyAutoLimit`.
|
|
*/
|
|
limit: 100,
|
|
|
|
setLimit: (value: number) => (sqlEditorSessionState.limit = value),
|
|
|
|
/**
|
|
* The logs time range for a logs snippet, keyed by snippet id. Session state —
|
|
* never written to snippet content — so it works on read-only shared snippets
|
|
* and resets on reload. An unset snippet has no entry; read sites fall back to
|
|
* `DEFAULT_LOG_DATE_RANGE`.
|
|
*/
|
|
logRange: {} as { [snippetId: string]: LogDateRange },
|
|
|
|
setLogRange: (id: string, range: LogDateRange) => {
|
|
sqlEditorSessionState.logRange[id] = range
|
|
},
|
|
|
|
addResult: (id: string, results: any[], autoLimit?: number) => {
|
|
// Use ref() to prevent Valtio from creating proxies for each row object.
|
|
// This is critical for large result sets - without ref(), Valtio wraps every
|
|
// row and nested property in a Proxy, causing massive memory overhead.
|
|
// Alright to use ref() in this case as the data is meant to be read-only and we
|
|
// don't need to track changes to the underlying data
|
|
sqlEditorSessionState.results[id] = [{ rows: ref(results), autoLimit }]
|
|
},
|
|
|
|
addResultError: (id: string, error: any, autoLimit?: number) => {
|
|
sqlEditorSessionState.results[id] = [{ rows: ref([]), error, autoLimit }]
|
|
},
|
|
|
|
resetResult: (id: string) => {
|
|
sqlEditorSessionState.results[id] = []
|
|
},
|
|
|
|
/** Drop all session state for a snippet (called when the snippet is removed). */
|
|
clearForSnippet: (id: string) => {
|
|
delete sqlEditorSessionState.results[id]
|
|
delete sqlEditorSessionState.logRange[id]
|
|
},
|
|
})
|
|
|
|
export const getSqlEditorSessionSnapshot = () => snapshot(sqlEditorSessionState)
|
|
|
|
export const useSqlEditorSessionSnapshot = (options?: Parameters<typeof useSnapshot>[1]) =>
|
|
useSnapshot(sqlEditorSessionState, options)
|