feat(sql): add SQL landing/overview page#2541
Draft
c-julin wants to merge 6 commits into
Draft
Conversation
Add a standalone landing/overview page as the default view for the /sql route, independent from the query editor studio. SqlPage switches between the landing and the editor (which gains a back-to-overview affordance); shared catalog/identity fetching is extracted into useSqlCatalogs. The landing renders only the data that has a real backend today (catalogs and tables, role, recent queries from localStorage, derived counts). Observability metric tiles and the connection-details card from the design have no backend yet and are documented as capability-gated extension points, so standalone deployments degrade gracefully without placeholder numbers.
Contributor
🚨 Registry drift detectedApp:
Components needing attention
Refresh command: bunx shadcn@latest add @redpanda/dropdown-menu @redpanda/tabs --overwriteGenerated by lookout audit-changes. |
Match the landing page layout width to line up with other pages and reduce unused space. The catalog and query rows used bg-selected-hover, an undefined token, so hovering did nothing; they were also plain buttons with no pointer cursor. Bump the catalog header to text-sm so it is no longer smaller than the table rows it groups.
r-vasquez
force-pushed
the
jc/sql-landing-page
branch
from
3cacc69 to
1cfbf54
Compare
- /sql is now a layout with real child routes: the landing at /sql and the editor at /sql/editor with seed/run/wizard search params — deep-linkable, back-button friendly, no sessionStorage view state - SQLService fallback redirect moved to the layout so it covers the landing - useSqlCatalogs tracks catalogs+tables+identity loading and exposes isError/refetch; the landing renders distinct loading and error states instead of flashing the empty-state onboarding, and only claims "Connected" after a successful load - query history extracted to sql-history.ts (one key+schema for editor and landing, cluster-scoped when embedded); landing-initiated auto-runs go through the editor's run path so they're recorded - landing rebuilt on registry Card/Spinner/Button primitives; shared previewSql helper; table-id keys; prettyMilliseconds timestamps - catalog/identity/table queries get a long staleTime (invalidation stays the freshness trigger); wizard topic listing fetches only when the wizard opens; SqlEditorView pass-through inlined; dark-border remap defined once
Sidebar items can now declare children rendered as a collapsible sub-menu (SidebarMenuSub + chevron SidebarMenuAction). The SQL entry exposes Editor, linking straight to /sql/editor without going via the landing page. The section auto-expands while a /sql route is active; the parent row highlights only on its exact page once a child can claim the highlight.
The workspace view is now consistently called Studio: the route moves from /sql/editor to /sql/studio, the sidebar sub-item reads Studio, and the landing CTAs become "Open studio" / "Browse in studio". Internal names for the CodeMirror text-editing pane (SqlEditor) are unchanged — that pane is an editor inside the studio.
The federation SidebarItem contract gains an optional children field so the host (Cloud UI) can render the SQL → Studio sub-item; updateSidebarItems maps the route children through. Hosts that ignore the field are unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a standalone landing/overview page as the default view for the
/sqlroute, independent from the query editor studio. Ported from the "RP SQL" design.sql-page.tsx— new/sqlroute component. Holds the view state (landing | editor, persisted per session) and switches between two independent experiences.sql-landing.tsx— the standalone overview: hero, derived-metric strip, catalogs & tables, suggested queries, recent queries, docs. No studio chrome.sql-workspace.tsx— the editor studio is now editor-only, with a back-to-overview arrow in its header, and accepts entry intent (seedQuery/autoRun/openWizardOnMount) from the landing.use-sql-catalogs.ts— shared catalog/identity/tables fetching, used by whichever view is mounted (only one at a time, so no double-fetch).Capability gating (embedded vs standalone)
The design shows data that has no backend in either deployment yet — observability metric tiles (queries·24h, p50 latency, bytes scanned, bridge-lag) and the connection-details card (host/port/JDBC/psql). The landing renders only the real, wireable data today (catalogs & tables, role, recent queries from
localStorage, derived counts), so standalone deployments degrade gracefully with no placeholder numbers. The unbacked sections are documented as capability-gated extension points insql-landing.tsx.Testing
sql-landing.test.tsx— 6 new tests (populated overview, suggested-query run, open-editor, recent-from-history, admin/viewer onboarding).ultracitelint clean.