Files
Charis Lam cc5548dbe0 refactor(studio): unify snippet save + persistence into SnippetStatus
PR 3 of a stacked refactor. Replaces the two overlapping pieces of snippet
lifecycle state — the savingStates map ('IDLE'|'UPDATING'|'UPDATING_FAILED')
and the isNotSavedInDatabaseYet boolean — with a single SnippetStatus enum.

Save progress and persistence are orthogonal, so the never-persisted 'new'
phase keeps its own saving/failed variants (new, new_saving, new_save_failed)
alongside the persisted ones (saved, unsaved, saving, save_failed). The
wasNeverPersisted() predicate recovers the persistence axis and stays true
across the entire first-save lifecycle, so content-fetching, list
invalidation, and the replication-lag 404 swallow all map faithfully — and a
new snippet's first save keeps its saving/failed indicator.

Status is attached at the data layer so a snippet is never without one:
- SnippetStatus + SnippetWithContent now live in data/content; the snippet
  queries attach status 'saved' via withSavedStatus(), and upsertContent
  returns SnippetWithContent so move/rename responses carry status too.
- A SQL-typed getSqlSnippetById/useSqlSnippetByIdQuery returns
  SnippetWithContent (the generic useContentIdQuery stays for Reports), so
  [id].tsx loads content with no casting.
- 'new' is attached on local creation (createSqlSnippetSkeletonV2).

Dependents import SnippetWithContent/SnippetStatus directly from the data
layer (no state-layer re-exports). 'unsaved' is reserved for manual-save
dirty tracking in a later PR. Pure unit tests for every predicate/transition.
2026-06-23 18:50:55 -04:00
..
2026-06-11 15:07:49 +02:00
2024-10-17 11:39:06 +02:00
2024-07-04 14:48:10 +08:00

Writing pages

Rough guidelines

  • Try to break down your pages into smaller building blocks - components which are tightly coupled to a page can be placed within the folder components/interfaces/xxx/... (Refer to the README.md under the components folder)
  • Keep to using useState hooks for any UI related logic, do not create MobX local stores to handle UI logic.

Template for building pages

import { NextPage } from 'next'
import { withAuth } from 'hooks/misc/withAuth'

// Import the corresponding layout based on the page
import { Layout } from 'components/layouts'

// Import the main building blocks of the page
import { ... } from 'components/interfaces/xxx'

// Import reusable UI components if needed
import { ... } from 'components/ui/xxx'

// Name your page accordingly
const Page: NextPage = () => {

  return (
    <Layout>
      <div>Page content</div>
    </Layout>
  )
}

export default withAuth(Page)