Views

Views are the screens your team sees in the Standards app. listView is the table of records; detailView is the page one record opens into. The ones you declare here are a starting point: on app.standards.new your users change them, add tabs and columns, and create views of their own, and sync keeps theirs while owning yours. Declare them next to your objects and they ship in the same schema.sync.

import { content, detailView, group, listView, query } from "@standards/client";

const IDENTITY = content.form(
  group("identity", "Identity").fields("firstName", "lastName", "email")
);

export const CONTACT_DETAIL = detailView("contact_detail", "Contact")
  .for("contacts")
  .default()
  .tab("general", "Info", IDENTITY)
  .tab("activity", "Activity", content.activity())
  .aside("details", "Details", content.form(group("details", "Details").field("status")))
  .build();

export const CONTACTS = listView("contacts_list", "Contacts")
  .for("contacts")
  .default()
  .tab("all", "All", content.collection(query("contacts")).table().columns("firstName", "email"))
  .build();

The view chain

Every call returns a new builder. A content has no name, label or placement of its own; the view supplies them. Content names are unique within a view, and at least one main content is required. Contents that need a record (everything except a collection on an object) are refused on a listView at build time.

The ten content types

content.collection(query)     // the records a typed query reads
content.form(...groups)       // fields of the current record, laid out in groups
content.activity()            // the record's activity feed
content.richtext("body")      // one richtext attribute, full width
content.documents()           // the record's document packs
content.forms().object("x")   // submissions of the form system for an object
content.emails("email")       // threads matched on email attributes
content.meetings("email")     // meetings matched on email attributes
content.custom(extension, o)  // a registered content extension
content.page(recordPage)      // a record page of the same object, by name

The block factories (content.metric, content.chart, content.agenda, content.card, content.text…) and content.page are described in Pages.

The attributes content.meetings names also link meetings to records: a synced meeting links every record whose attribute holds one of its participants' addresses, and follows a later change of that value, so a contact whose address is filled in or corrected after the meeting was synced is linked or unlinked without a new sync. Links added by hand are kept.

On a record, the tab strip follows the label of a collection or documents tab with the number of items it lists: a collection counts the records its query and relation select (not what someone typed into its search or filters), and documents count the files and folders at the root of the record's drive (each once, nothing inside a folder). Each count respects what the viewer may see and is read without opening the tab. A tab with nothing in it, or whose count has not arrived, shows only its label. Emails, meetings, a documents tab that hides attachments, and tabs without a list behind them carry no count.

All of them accept .icon(name). content.custom names an extension already registered on the platform; the extension registry itself is not part of the client surface.

The Bubble tab

The default record view of an object created from now on, and the native views (meeting, artifact, skill, memory), include a Bubble tab: a custom content on the record_links block that maps the links around the record (see Blocks). An existing view gains it from the "+" tab menu. A view you declare in code does not get it for free: add it with the helper from @standards/schema, or place the block yourself:

import { RECORD_LINKS_BLOCK, content, detailView, recordLinksTab } from "@standards/schema";

detailView("contact_detail", "Contact")
  .for("contacts")
  .tab(...recordLinksTab()) // name "bubble", label "Bubble"
  // or, with your own name and label:
  .tab("links", "Links", content.custom(RECORD_LINKS_BLOCK, {}))
  .build();

Collections

A collection reads the records of one typed query(...): an object, a relation the current record declares (query(target).related(attribute)), or the records whose own relation points back at the current record (query(object).relatedFrom(attribute)). related needs one concrete target object; polymorphic and universal relations are not a collection source. The query carries the filters and sorts, so the collection has no .object, .related, .relatedFrom, .filter or .sort of its own.

import { content, detailView, query } from "@standards/client";

export const COMPANY_DETAIL = detailView("company_detail", "Company")
  .for("companies")
  .tab("contacts", "Contacts", content.collection(
    query("contacts").relatedFrom("company").orderBy("lastName"))
    .table()
    .columns("firstName", "lastName", "email")
    .openMode("peek")
    .createMode("inline")
    .actions("create", "update", "delete"))
  .build();

query(...) is immutable: every verb returns a new query. It takes an object builder, which checks attribute names, or an object name. Its verbs are eq, neq, gt, gte, lt, lte, contains, notContains, startsWith, endsWith, in, notIn, isEmpty, isNotEmpty, or, orderBy, limit, offset, search, related and relatedFrom. A rule value can be a dynamic value that is resolved for whoever reads the view: currentActor(), today() or now(). A collection stores the query's source, filters, sorts and limit: content.collection(q) refuses a query with search or offset with a ValidationError.

import { content, currentActor, query, today } from "@standards/client";

content.collection(
  query("tasks").eq("assignee", currentActor()).lt("dueDate", today()).orderBy("dueDate")
).list();

where(...rules) appends rules exactly as written, for what the verbs do not cover: any operator, a qualified relation property, or a quantifier on a qualified property.

query("deals").where({ attribute: "contacts", property: "signedDate", operator: "is_not_empty", value: null });

The same query also feeds aggregate().

Actions never grant permissions: a user without update on the object does not gain it from a collection.

Forms inside a view

group(name, label) holds fields: .field(attribute, { label?, span?, readOnly? }) or .fields(...attributes), plus .description(text) and .collapsible(collapsed?). content.form(...groups) accepts .formColumns(1 | 2 | 3) and .density("comfortable" | "compact" | "spacious").

Views in a source

Pass views next to the objects. Each one is built and validated locally, then sent with the objects on the next schema.sync.

import { defineSchemaSource } from "@standards/client";

export const crmSource = defineSchemaSource({
  id: "crm",
  objects: [CONTACT, COMPANY],
  views: [CONTACT_DETAIL, CONTACTS, COMPANY_DETAIL],
});

On the workspace a source-owned view is adopted the first time it is pushed, updated on every later change, and released when it leaves the source: the row becomes a custom view and workspace overlays survive. Declaring it again adopts the row back. The Sync page shows these counters in the SyncResult.

Next steps

• Relations and documents: the sources a collection can read
• Blocks: declare a block and the inputs it takes
• Sync: push objects and views in one call
• Objects: the objects your views point at
• Schema sources: what a workspace keeps when a view is released
• Book a demo