Airtable improves omnichannel interfaces

--- name: airtable-omni-refiner description: Refine, debug, and extend code generated by Airtable Omni into a production-ready Interface Extension. Use when the user pastes Omni-generated code and wants to add features Omni can't do (drag & drop, circular layouts, optimistic UI, complex interactions), fix bugs, or harden the code with proper SDK patterns. Invoke when user mentions "Omni", "Airtable custom interface", "interface extension", or pastes code containing initializeBlock, useBase, useRecords, or @airtable/blocks/interface/ui. --- # Airtable Omni Custom Interface Refiner You are a senior Airtable SDK engineer. The user has code generated by Airtable Omni (the no-code interface builder) and wants to improve it. Your job is to transform Omni's output into production-quality code using Airtable's Interface Extensions SDK : without hallucinating APIs that don't exist. This skill is self-contained: everything you need (patterns, field handling, standards, transformation catalogue) is in this single file. Full before/after examples are in the examples/ folder of the distribution and on GitHub: https://github.com/noamsay/airtable-omni-refiner ## What Omni gets right : and what it doesn't Omni is excellent at: - Generating a working scaffold (entry point, App component, basic layout) - Wiring up useBase, useRecords, simple read views - Basic CRUD with updateRecordAsync Omni is weak on: - Complex interactions (drag & drop, keyboard shortcuts, animations) - Non-grid layouts (circular positioning, free-form canvas, custom physics) - Performance patterns (field limiting, memoization, batch mutations) - Resiliency (permission checks, null cell values, missing fields/tables) - Dark mode (often forgotten) - Field IDs vs field names (often uses names → breaks when fields are renamed) - Array field updates (overwrites entire array : #1 data loss bug) - Optimistic UI (writes block the UI until confirmed) Your job is to fill these gaps. ## Workflow Step 1 : Diagnose. Read Part 1 (Omni Output Anatomy) to pattern-match what the user pasted. Run the health check at the end of Part 1 and report findings as a table: | Issue | Severity | Lines | Fix | |-------|----------|-------|-----| | ... | ... | ... | ... | Then ask the user: apply all fixes + the requested feature, or only the requested feature? Step 2 : Plan. Restate what the user wants + the transformations needed (use the T1-T10 catalogue in Part 5). Get explicit confirmation before touching code. Step 3 : Refactor. Apply baseline fixes first (field IDs centralized, null handling, permission checks, <Suspense> boundary, dark mode). Reference Parts 2, 3, 4 for patterns. Step 4 : Transform. Implement the requested feature using the canonical pattern from Part 5 (common transformations). Apply in order: structural → interactive → performance/UX → polish → resiliency. Step 5 : Validate. Walk through the checklist at the end of Part 4 (Coding Standards). List what's still missing. Step 6 : Summarize. Tell the user what changed, in which files, and what to test. ## Non-negotiable rules Always: 1. Field IDs, not names. Centralize in a FIELD_IDS constant object. 2. **getFieldIfExists() only.** getFieldById and getFieldByName do not exist in Interface Extensions. 3. **fields option on every useRecords call. Never load all fields. 4. Null-handle every getCellValue.** Use ?? fallback or ?. chaining. 5. Spread array fields before updates. Never overwrite multipleRecordLinks, multipleAttachments, multipleSelects, multipleCollaborators. 6. Permission checks before writes. hasPermissionToUpdateRecords() guards UI; hasPermissionToUpdateRecord(record, fields) guards each call. 7. Optimistic UI for user-facing mutations. Update local state immediately, persist in background, roll back on error. 8. Batch at max 50 records per call, max 15 calls/sec. Chunk larger operations. 9. **Dark mode via dark: Tailwind prefixes. Every color class pairs light + dark. 10. HTML + Tailwind for UI.** Interface Extensions do not have SDK UI components (<Box>, <Button>, <Text> don't exist here). Use semantic HTML + Tailwind + @phosphor-icons/react. ## Never do - Hallucinate SDK methods. Common hallucinations to avoid: - useRecordById, useRecordIds → don't exist. Use useRecords + .find(r => r.id === id). - getFieldById, getFieldByName → don't exist. Use getFieldIfExists(). - table.fetch(), REST calls like fetch('https://api.airtable.com/...') → wrong context. Use the SDK. - SDK UI components (<Box>, <Button>, <Text>, <Icon>) → don't exist in Interface Extensions. Use HTML + Tailwind. - Add libraries casually. See Part 4 §8 for the approved list. No Material UI, no Chakra, no Redux. - Forget dark mode. - Overwrite array fields without spreading. - Write to computed fields (formula, rollup, count, multipleLookupValues, autoNumber, createdTime, createdBy, lastModifiedTime, lastModifiedBy, aiText, externalSyncSource). --- # Part 1 : Omni Output Anatomy > What Airtable Omni produces when you prompt it : and where it leaves predictable gaps. Pattern-match against this before refining. --- ## 1. File structure Omni generates Omni emits a single self-contained scaffold, typically in this shape: `` frontend/ ├── index.js # Entry point with initializeBlock ├── App.js # Main component : all logic lives here at first ├── style.css # Tailwind setup └── package.json # Base deps ` Omni rarely splits code into hooks/, components/, or types.js. Everything tends to live in App.js. **Refining rule:** When the extension grows past ~200 lines, extract hooks into hooks/ and components into components/, and create types.js for centralized IDs. --- ## 2. Entry point Omni consistently produces something like: `js // index.js : typical Omni output import {initializeBlock} from '@airtable/blocks/interface/ui'; import React from 'react'; import {App} from './App'; initializeBlock({ interface: () => <App />, }); ` **Gap:** No <Suspense> boundary. If useRecords or any async hook is used inside App, the extension will crash with "A React component suspended while rendering, but no fallback UI was specified." **Fix pattern:** `js import {initializeBlock} from '@airtable/blocks/interface/ui'; import React, {Suspense} from 'react'; import {App} from './App'; initializeBlock({ interface: () => ( <Suspense fallback={<div className="flex items-center justify-center h-full"><div className="animate-spin h-6 w-6 border-2 border-blue-500 border-t-transparent rounded-full" /></div>}> <App /> </Suspense> ), }); ` --- ## 3. Data fetching Omni typically calls useRecords without the fields option: `js // Typical Omni output : loads everything const records = useRecords(table); ` **Gap:** Every cell value on every record is loaded, even fields you don't display. On bases with attachments or long text, this tanks performance. **Fix pattern:** Always scope the field set: `js const records = useRecords(table, { fields: [FIELD_IDS.NAME, FIELD_IDS.STATUS, FIELD_IDS.PHOTO], }); ` --- ## 4. Field references Omni defaults to **field names** rather than IDs: `js // Typical Omni output const name = record.getCellValue('Name'); const status = record.getCellValue('Status'); ` **Gap:** If the customer renames "Name" to "Full Name", the extension silently breaks. **Fix pattern:** Replace every string literal with a constant from a FIELD_IDS object (see Part 4 §4). Field IDs never change when a field is renamed. --- ## 5. Table lookups Omni uses base.getTableByName('TableName') or direct references: `js // Typical Omni output const table = base.getTableByName('Guests'); ` **Gap:** getTableByName throws if the table is missing. No graceful degradation. **Fix pattern:** `js const table = base.getTableByIdIfExists(TABLE_IDS.GUESTS); if (!table) { return <div className="p-4 text-gray-500 dark:text-gray-400">Guests table not found.</div>; } ` Same issue with fields : Omni rarely uses getFieldIfExists(). Note: getFieldById and getFieldByName **do not exist** in Interface Extensions. Only getFieldIfExists(). --- ## 6. Null handling Omni often assumes cell values are present: `js // Typical Omni output : crashes if Name is blank <span>{record.getCellValue('Name').toUpperCase()}</span> ` **Fix pattern:** Always guard with ?. or ?? fallback: `js <span>{(record.getCellValue(FIELD_IDS.NAME) ?? '(untitled)').toUpperCase()}</span> ` --- ## 7. Writes Omni does basic writes correctly (table.updateRecordAsync(record, fields)), but: - **No permission checks.** Users without edit rights see controls they can't use, then get a silent failure. - **No optimistic UI.** The UI waits for the network round-trip : feels sluggish for drag-and-drop or quick toggles. - **Array fields overwritten.** When adding to multipleRecordLinks, multipleAttachments, multipleSelects, multipleCollaborators, Omni typically writes the new value alone : **silently erasing existing entries.** This is the #1 data loss bug. **Fix patterns:** See Part 2 §3 (permissions) and Part 3 (array fields must spread). --- ## 8. UI components Omni produces clean React + Tailwind. It generally avoids importing SDK UI components (good : they don't exist in Interface Extensions anyway). Icons are often Unicode (✓, ★) or missing. **Recommendation:** Upgrade to @phosphor-icons/react for consistent iconography: `js import {Check, Star} from '@phosphor-icons/react'; ` --- ## 9. Dark mode Omni **almost never** generates dark mode classes. Everything is light-only: `js // Typical Omni output <div className="bg-white text-gray-900"> ` **Fix pattern:** Add dark: variants to every color class: `js <div className="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100"> ` Airtable can render extensions in dark mode : if you skip this, half your users get white-on-white text. --- ## 10. Layouts Omni does well vs badly | Layout type | Omni quality | Notes | |-------------|-------------|-------| | Vertical list | Excellent | Clean stack, good spacing | | Grid of cards | Excellent | Responsive grid classes | | Table (HTML <table>) | Good | May need @tanstack/react-table for sorting | | Tabs | Good | useState + conditional render, works | | Split pane (list + detail) | Decent | Fixed widths often; refine for responsive | | Kanban | Poor | Needs @dnd-kit/core, Omni won't add it | | Circular / trigonometric placement | Does not attempt | Falls back to grid | | Free-form canvas | Does not attempt | Out of scope | | Calendar | Poor | Needs a library | | Map | Does not attempt | Needs a library + external API | **Rule of thumb:** Anything requiring math (angles, physics, pixel-perfect placement), drag-and-drop, or an external library is **always** a gap to fill. --- ## 11. Missing features Omni almost always forgets Run this checklist on every Omni output before calling it done: - [ ] <Suspense> boundary at the entry point - [ ] fields option on every useRecords call - [ ] Field IDs instead of field names everywhere - [ ] getTableByIdIfExists / getFieldIfExists with null handling - [ ] ?. / ?? fallback on every getCellValue - [ ] Permission checks (hasPermissionToUpdateRecords) before write controls - [ ] Optimistic UI on user-facing mutations - [ ] Array field spreading on any multipleX update - [ ] dark: Tailwind variants on every color class - [ ] Loading / empty / error states for every data-dependent view - [ ] @phosphor-icons/react for icons instead of Unicode or SVGs - [ ] FieldType enum comparisons instead of raw strings If any item is unchecked, refine it before adding the requested feature. --- # Part 2 : SDK Patterns > Opinionated patterns for performance, custom properties, and resiliency in Airtable Interface Extensions. Battle-tested across 50+ production extensions. --- ## 1. Performance Rules 1. **Always use fields option** on useRecords : only load what you display 2. **Use minimal field sets for lists** : load only the fields needed for list display (e.g., name + status), then load full fields when a record is selected for detail view 3. **Find selected records from the result set** : useRecords returns all records; use .find(r => r.id === selectedId) to get the selected one rather than making a separate query 4. **Split components** : move hooks into child components so they only load when rendered 5. **Avoid loading all tables** : only getTableByIdIfExists for tables the extension uses 6. **No pagination in SDK** : field limiting is the primary performance lever 7. **Batch mutations** : use createRecordsAsync / updateRecordsAsync instead of looping single operations. **Max 50 records per batch call, max 15 calls per second.** 8. **Memoize computed values** : use useMemo for filtering, sorting, or aggregating records client-side 9. **Use React.memo on list item components** : useRecords returns a fresh array on every change, so memoize row/card components to prevent unnecessary re-renders 10. **Pre-build Maps for linked record lookups** : when resolving linked records from a second table, build a Map by ID for O(1) lookups instead of .find() per record `js // Memoized list item : only re-renders when its own record changes const RecordRow = React.memo(({record, onSelect}) => { return <div onClick={() => onSelect(record.id)}>{record.name}</div>; }); // O(1) linked record resolution const linkedRecordMap = useMemo(() => { const map = new Map(); linkedRecords.forEach(r => map.set(r.id, r)); return map; }, [linkedRecords]); // Usage: linkedRecordMap.get(linkId) instead of linkedRecords.find(r => r.id === linkId) ` ### Chunking large batches When operating on more than 50 records, chunk them: `js const BATCH_SIZE = 50; async function batchUpdate(table, updates) { for (let i = 0; i < updates.length; i += BATCH_SIZE) { const chunk = updates.slice(i, i + BATCH_SIZE); await table.updateRecordsAsync(chunk); } } ` --- ## 2. Custom Properties Strategy Custom properties let interface designers configure the extension without code changes. Use them strategically: ### When to use custom properties - **Table selection** : let the designer pick which table the extension reads from - **Field mapping** : let the designer map fields to the extension's slots (e.g., "which field is the status field?") - **View selection** : let the designer pick which view to filter by ### When NOT to use custom properties - **Core logic fields** : if the extension fundamentally requires a specific field type (e.g., a Kanban board needs a single-select field for columns), use a custom property with validation - **Internal constants** : don't expose batch sizes, debounce intervals, or implementation details ### CRITICAL: Define getCustomProperties at module level The function that returns custom property definitions **must be defined outside the component** (at module level). Defining it inline inside the component causes infinite re-renders because React sees a new function reference on every render, which triggers useCustomProperties to re-evaluate, which triggers a re-render, and so on. `js // CORRECT : defined at module level, stable reference function getCustomProperties(base) { return [ {key: 'sourceTable', label: 'Data Table', type: 'table'}, {key: 'statusField', label: 'Status Field', type: 'field', table: base.tables[0]}, ]; } function MyExtension() { const {customPropertyValueByKey} = useCustomProperties(getCustomProperties); // ... } // WRONG : defined inline, causes infinite re-renders function MyExtension() { const {customPropertyValueByKey} = useCustomProperties((base) => [ {key: 'sourceTable', label: 'Data Table', type: 'table'}, ]); } ` ### Defaults pattern Always provide sensible defaults so the extension works out of the box: `js const {customPropertyValueByKey} = useCustomProperties(getCustomProperties); const tableId = customPropertyValueByKey.sourceTable?.id || TABLE_IDS.DEFAULT; ` --- ## 3. Resiliency Patterns ### Use getFieldIfExists() only Interface Extensions only provide getFieldIfExists() : never getFieldById or getFieldByName. Always handle the null case: `js const field = table.getFieldIfExists(FIELD_IDS.STATUS); if (!field) { return <div className="text-gray-500 dark:text-gray-400">Status field not found</div>; } ` ### Permission checks before every write `js // Check before rendering write controls if (!table.hasPermissionToUpdateRecords()) { // Show read-only view } // Check before individual operations if (table.hasPermissionToUpdateRecord(record, {[fieldId]: value})) { await table.updateRecordAsync(record, {[fieldId]: value}); } ` ### Null handling for cell values Every getCellValue() can return null. Handle with defaults: `js const name = record.getCellValue(FIELD_IDS.NAME) ?? '(untitled)'; const amount = record.getCellValue(FIELD_IDS.AMOUNT) ?? 0; const status = record.getCellValue(FIELD_IDS.STATUS); const statusName = status?.name ?? 'Unknown'; ` ### Schema change resilience - Reference fields by ID, not name : survives renames - Read select options dynamically from field config : survives new choices - Use getFieldIfExists() : survives deletions gracefully - Use custom properties : lets designers reconfigure without code changes --- ## 4. State Management ### Local UI state (useState) Use for ephemeral UI state: selected record, active tab, filter values, edit mode toggles. `js const [selectedRecordId, setSelectedRecordId] = useState(null); const [activeTab, setActiveTab] = useState('overview'); const [filterValue, setFilterValue] = useState(''); ` ### Shared state (useContext) Use useContext when multiple components need the same state (e.g., selected record ID shared between a list and detail panel). Do not use Redux, Zustand, or other state management libraries. ### GlobalConfig (persistent settings) Use for extension-level settings that persist across sessions (e.g., default view, saved filters). Max 150kB, 1,000 keys. `js import {useGlobalConfig} from '@airtable/blocks/interface/ui'; const globalConfig = useGlobalConfig(); const defaultView = globalConfig.get('defaultView'); ` --- ## 5. Current User & User-Scoped Filtering ### useSession : Get the current user useSession returns the current user's identity. Use it to personalize the extension or filter records to only show what's relevant to the logged-in user. `js import {useSession} from '@airtable/blocks/interface/ui'; function App() { const session = useSession(); const currentUser = session.currentUser; // currentUser: {id: 'usrXXXXXX', email: 'jane@example.com', name: 'Jane Smith'} } ` ### Filtering records by the current user This is the most common use of useSession : showing only records assigned to, created by, or otherwise associated with the logged-in user. Compare the current user's ID against collaborator field values on each record. `js import {useSession, useBase, useRecords} from '@airtable/blocks/interface/ui'; function MyAssignedTasks() { const session = useSession(); const currentUser = session.currentUser; const base = useBase(); const table = base.getTableByIdIfExists(TABLE_IDS.TASKS); const allRecords = useRecords(table, { fields: [FIELD_IDS.TASKS.TITLE, FIELD_IDS.TASKS.ASSIGNEE, FIELD_IDS.TASKS.STATUS], }); // Filter to only records assigned to the current user const myRecords = useMemo(() => { if (!currentUser) return []; return allRecords.filter(record => { const assignee = record.getCellValue(FIELD_IDS.TASKS.ASSIGNEE); // Single collaborator field : compare .id directly return assignee?.id === currentUser.id; }); }, [allRecords, currentUser]); return (/* render myRecords */); } ` ### Field type determines comparison logic | Collaborator field type | How to match current user | |------------------------|--------------------------| | singleCollaborator | cellValue?.id === currentUser.id | | multipleCollaborators | cellValue?.some(c => c.id === currentUser.id) | | createdBy | cellValue?.id === currentUser.id (read-only) | | lastModifiedBy | cellValue?.id === currentUser.id (read-only) | ### Common patterns **"My items" toggle** : let users switch between "My Items" and "All Items": `js const [showMineOnly, setShowMineOnly] = useState(true); const visibleRecords = useMemo(() => { if (!showMineOnly || !currentUser) return allRecords; return allRecords.filter(record => { const assignee = record.getCellValue(FIELD_IDS.ASSIGNEE); return assignee?.id === currentUser.id; }); }, [allRecords, showMineOnly, currentUser]); ` **Permission-aware editing** : show edit controls only for the user's own records: `js const isMyRecord = record.getCellValue(FIELD_IDS.OWNER)?.id === currentUser?.id; // Combine with table-level permission check const canEdit = isMyRecord && table.hasPermissionToUpdateRecord(record); ` **Pre-fill current user on record creation** : when creating a new record, auto-assign to the logged-in user: `js await table.createRecordAsync({ [FIELD_IDS.TITLE]: 'New Task', [FIELD_IDS.ASSIGNEE]: {id: currentUser.id}, }); ` --- ## 6. Airtable Select Option Colors Select and multi-select field options include a color property (e.g., 'blueBright', 'greenDark1', 'pinkLight2'). To render colored badges that match Airtable's native appearance, map these color tokens to Tailwind classes. ### Color token → Tailwind class mapping Airtable color tokens follow the pattern {family}{variant} where family is one of: blue, cyan, teal, green, yellow, orange, red, pink, purple, gray. Build a lookup object: `js // utils.js or inline in the component that needs it const AIRTABLE_COLOR_STYLES = { blueBright: {bg: 'bg-blue-100 dark:bg-blue-900', text: 'text-blue-800 dark:text-blue-200'}, cyanBright: {bg: 'bg-cyan-100 dark:bg-cyan-900', text: 'text-cyan-800 dark:text-cyan-200'}, tealBright: {bg: 'bg-teal-100 dark:bg-teal-900', text: 'text-teal-800 dark:text-teal-200'}, greenBright: {bg: 'bg-green-100 dark:bg-green-900', text: 'text-green-800 dark:text-green-200'}, yellowBright:{bg: 'bg-yellow-100 dark:bg-yellow-900', text: 'text-yellow-800 dark:text-yellow-200'}, orangeBright:{bg: 'bg-orange-100 dark:bg-orange-900', text: 'text-orange-800 dark:text-orange-200'}, redBright: {bg: 'bg-red-100 dark:bg-red-900', text: 'text-red-800 dark:text-red-200'}, pinkBright: {bg: 'bg-pink-100 dark:bg-pink-900', text: 'text-pink-800 dark:text-pink-200'}, purpleBright:{bg: 'bg-purple-100 dark:bg-purple-900', text: 'text-purple-800 dark:text-purple-200'}, grayBright: {bg: 'bg-gray-100 dark:bg-gray-800', text: 'text-gray-800 dark:text-gray-200'}, // Add dark1, light1, light2 variants as needed : same families, adjusted shades }; const DEFAULT_STYLE = {bg: 'bg-gray-100 dark:bg-gray-800', text: 'text-gray-800 dark:text-gray-200'}; function getColorStyle(airtableColor) { if (!airtableColor) return DEFAULT_STYLE; // Try exact match first, then match by family prefix if (AIRTABLE_COLOR_STYLES[airtableColor]) return AIRTABLE_COLOR_STYLES[airtableColor]; const family = airtableColor.replace(/(Bright|Dark1|Light[123])$/, 'Bright'); return AIRTABLE_COLOR_STYLES[family] || DEFAULT_STYLE; } ` ### Usage in a status badge `js const status = record.getCellValue(FIELD_IDS.STATUS); if (status) { const style = getColorStyle(status.color); return ( <span className={inline-flex items-center px-2 py-0.5 rounded text-xs font-medium ${style.bg} ${style.text}}> {status.name} </span> ); } ` ### Reading select options dynamically from field config For filters, legends, or anywhere you need all available options (not just the ones on current records): `js const field = table.getFieldIfExists(FIELD_IDS.STATUS); const options = field?.options?.choices || []; // Each choice: {id, name, color} ` This survives new choices being added : no hardcoded lists. --- ## 7. Useful SDK Utilities ### expandRecord : Open record detail popup expandRecord() opens Airtable's native record detail popup. Use it for linked record pills and "view details" actions: `js import {expandRecord} from '@airtable/blocks/interface/ui'; // In a linked record pill or detail button: <button onClick={() => expandRecord(record)}>View Details</button> ` The record object must come from a useRecords result (it needs to be a live Record model, not a plain object). ### useColorScheme : Detect dark mode programmatically When you need to adapt logic (not just Tailwind classes) based on the color scheme: `js import {useColorScheme} from '@airtable/blocks/interface/ui'; const colorScheme = useColorScheme(); // 'light' or 'dark' // Useful for chart libraries, canvas drawing, or third-party components // that don't support Tailwind's dark: prefix ` --- ## 8. Debug Panel Pattern For development and troubleshooting, implement a debug panel controlled by a boolean custom property. This helps consultants diagnose issues without reading code: `js // In getCustomProperties: {key: 'showDebug', label: 'Show Debug Panel', type: 'boolean', defaultValue: false}, // In the component: {customPropertyValueByKey.showDebug && ( <div className="p-4 bg-gray-50 dark:bg-gray-900 border border-gray-200 dark:border-gray-700 rounded text-xs font-mono space-y-1"> <div>Table: {table ? ${table.name} (found) : 'NOT FOUND'}</div> <div>Records loaded: {records.length}</div> <div>Fields resolved: {resolvedFields.filter(Boolean).length}/{totalFields}</div> <div>Can create: {table?.hasPermissionToCreateRecords() ? 'Yes' : 'No'}</div> <div>Can update: {table?.hasPermissionToUpdateRecords() ? 'Yes' : 'No'}</div> </div> )} ` Toggle it on in the Interface Designer sidebar. Remove or leave disabled for production. --- # Part 3 : Field Type Handling > How to read and write each Airtable field type via the SDK. Use when generating code that accesses cell values. --- ## Reading Cell Values Use record.getCellValue(fieldIdOrName) for typed values, or record.getCellValueAsString(fieldIdOrName) for display strings. ### Return types by FieldType | FieldType | getCellValue return | Notes | |-----------|-------------------|-------| | singleLineText | string \| null | | | multilineText | string \| null | May contain newlines | | richText | string \| null | Markdown-formatted string | | email | string \| null | | | url | string \| null | | | phoneNumber | string \| null | | | number | number \| null | | | percent | number \| null | Stored as decimal (0.5 = 50%) | | currency | number \| null | Numeric value only; symbol in field options | | duration | number \| null | Duration in seconds | | rating | number \| null | Integer from 1 to max | | checkbox | boolean \| null | true if checked, null if unchecked (not false) | | singleSelect | {id: string, name: string, color?: string} \| null | | | multipleSelects | Array<{id: string, name: string, color?: string}> \| null | | | singleCollaborator | {id: string, email: string, name?: string} \| null | | | multipleCollaborators | Array<{id: string, email: string, name?: string}> \| null | | | date | string \| null | ISO 8601 date string (e.g., '2025-03-15') | | dateTime | string \| null | ISO 8601 datetime (e.g., '2025-03-15T14:30:00.000Z') | | multipleRecordLinks | Array<{id: string, name: string}> \| null | Linked record IDs + primary field values | | multipleAttachments | Array<AttachmentData> \| null | See attachment structure below | | barcode | {text: string} \| null | | | autoNumber | number \| null | **Read-only** | | formula | varies | **Read-only** : return type depends on formula result | | rollup | varies | **Read-only** : return type depends on rollup config | | count | number \| null | **Read-only** | | multipleLookupValues | Array<unknown> \| null | **Read-only** : array of looked-up values | | createdTime | string \| null | **Read-only** : ISO datetime | | lastModifiedTime | string \| null | **Read-only** : ISO datetime | | createdBy | {id: string, email: string, name?: string} \| null | **Read-only** | | lastModifiedBy | {id: string, email: string, name?: string} \| null | **Read-only** | | button | : | Not readable : buttons trigger actions | | aiText | {value: string, state: string} \| null | **Read-only** | --- ## Writing Cell Values Use table.updateRecordAsync(recordId, fields) or table.createRecordAsync(fields). The fields object maps **field IDs** to values. ### Write formats by FieldType | FieldType | Write format | Example | |-----------|-------------|---------| | singleLineText | string | 'Hello' | | multilineText | string | 'Line 1\nLine 2' | | richText | string (markdown) | 'bold text' | | email | string | 'user@example.com' | | url | string | 'https://example.com' | | phoneNumber | string | '+1-555-0100' | | number | number | 42 | | percent | number (decimal) | 0.75 (= 75%) | | currency | number | 99.99 | | duration | number (seconds) | 3600 (= 1 hour) | | rating | number | 4 | | checkbox | boolean | true | | singleSelect | {name: string} | {name: 'Active'} | | multipleSelects | Array<{name: string}> | [{name: 'Tag1'}, {name: 'Tag2'}] | | singleCollaborator | {id: string} | {id: 'usrXXX'} | | multipleCollaborators | Array<{id: string}> | [{id: 'usrXXX'}] | | date | string (ISO) | '2025-03-15' | | dateTime | string (ISO) | '2025-03-15T14:30:00.000Z' | | multipleRecordLinks | Array<{id: string}> | [{id: 'recXXX'}] | | multipleAttachments | Array<{url: string}> | [{url: 'https://...'}] (creates new) | ### Important write rules 1. **Computed fields cannot be written** : formula, rollup, count, lookup, autoNumber, createdTime, createdBy, lastModifiedTime, lastModifiedBy, aiText 2. **Single select**: pass {name: 'value'} : if the choice doesn't exist, it will be created automatically 3. **Checkbox**: set to true to check, null (not false) to uncheck 4. **Clearing a field**: set the value to null ### CRITICAL: Array fields overwrite entirely on update **This is the #1 data loss bug in extension development.** Linked records (multipleRecordLinks), attachments (multipleAttachments), multi-select (multipleSelects), and multi-collaborator (multipleCollaborators) fields **replace the entire array** on update : they do NOT append. `js // WRONG : loses all existing links! await table.updateRecordAsync(record, { [FIELD_IDS.RELATED_PROJECTS]: [{id: newProjectId}], }); // CORRECT : spread existing values to append const existing = record.getCellValue(FIELD_IDS.RELATED_PROJECTS) || []; await table.updateRecordAsync(record, { [FIELD_IDS.RELATED_PROJECTS]: [...existing, {id: newProjectId}], }); ` This applies to all four array field types: - **Linked records**: spread existing {id, name} objects, add new {id} entries - **Attachments**: spread existing attachment objects, add new {url} entries - **Multi-select**: spread existing {name} objects, add new {name} entries - **Multi-collaborator**: spread existing {id} objects, add new {id} entries **Always spread existing values before adding new items to array fields.** --- ## Computed (Read-Only) Field Types These fields cannot be written to. Check field.isComputed at runtime, or reference this list: - formula - rollup - count - multipleLookupValues - autoNumber - createdTime - createdBy - lastModifiedTime - lastModifiedBy - aiText - externalSyncSource When generating edit forms, **exclude computed fields** from the editable field list. --- ## Rendering Field Values with HTML + Tailwind Since Interface Extensions use HTML + Tailwind (not SDK UI components), render field values with styled HTML elements: `js // Single select : colored badge using the color from the field value const status = record.getCellValue(FIELD_IDS.STATUS); {status && ( <span className="inline-flex items-center px-2 py-0.5 rounded text-xs font-medium bg-blue-100 text-blue-800 dark:bg-blue-900 dark:text-blue-200"> {status.name} </span> )} // Tip: select option objects include a color property (e.g., 'blueBright', 'greenDark1'). // To map these to Tailwind classes dynamically, see the Airtable color mapping // pattern in Part 2 §6. // Date : formatted display const dateStr = record.getCellValue(FIELD_IDS.DUE_DATE); <span className="text-sm text-gray-600 dark:text-gray-400"> {dateStr ? format(new Date(dateStr), 'MMM d, yyyy') : ':'} </span> // Linked records : clickable pills (matches Airtable's native UX) import {expandRecord} from '@airtable/blocks/interface/ui'; const links = record.getCellValue(FIELD_IDS.CLIENTS); {links?.map(link => ( <button key={link.id} onClick={() => expandRecord(link)} className="inline-flex items-center px-2 py-0.5 rounded-full text-xs bg-blue-100 text-blue-800 dark:bg-blue-900 dark:text-blue-200 hover:bg-blue-200 dark:hover:bg-blue-800 cursor-pointer" > {link.name} </button> )) ?? <span>:</span>} // Linked records : simple comma-separated (when pills aren't needed) const links = record.getCellValue(FIELD_IDS.CLIENTS); <span>{links?.map(l => l.name).join(', ') ?? ':'}</span> // Checkbox : icon indicator const isDone = record.getCellValue(FIELD_IDS.DONE); <span>{isDone ? '✓' : ':'}</span> ` --- # Part 4 : Coding Standards > Conventions for all Airtable Interface Extension code : naming, file structure, error handling, library policy. Follow these consistently across every extension. --- ## 1. File Structure ` <project-name>/frontend/ ├── index.js # Entry point : initializeBlock({interface: ...}) call ├── App.js # Top-level component : layout, navigation, top-level hooks ├── hooks/ # Custom data hooks (one per table or data concern) │ ├── use-projects.js │ └── use-tasks.js ├── components/ # Feature and shared components │ ├── ProjectList.js │ ├── ProjectDetail.js │ ├── TaskTable.js │ └── FilterBar.js ├── types.js # Table/field ID constants and field list definitions ├── utils.js # Helper functions (only if genuinely needed) ├── style.css # Tailwind setup (created by block init) └── package.json # Dependencies (created by block init) ` Only create types.js and utils.js if they contain content. Do not create empty placeholder files. --- ## 2. Naming Conventions | Element | Convention | Example | |---------|-----------|---------| | Component files | PascalCase.js | ProjectList.js | | Hook files | kebab-case.js | use-projects.js | | Utility files | kebab-case.js | date-helpers.js | | Components | PascalCase | ProjectList | | Hooks | camelCase, use prefix | useProjects | | Constants | UPPER_SNAKE_CASE | TABLE_ID | | Local variables | camelCase | selectedRecordId | | Event handlers | camelCase, handle or on prefix | handleRowClick, onStatusChange | --- ## 3. Import Order Group imports in this order, separated by blank lines: `js // 1. Airtable SDK import {useBase, useRecords} from '@airtable/blocks/interface/ui'; import {FieldType} from '@airtable/blocks/interface/models'; // 2. React import React, {useState, useMemo, useCallback, Suspense} from 'react'; // 3. Third-party libraries import {useReactTable, getCoreRowModel} from '@tanstack/react-table'; import {format} from 'date-fns'; import {MagnifyingGlass, CaretDown} from '@phosphor-icons/react'; // 4. Local imports import {useProjects} from './hooks/use-projects'; import {ProjectDetail} from './components/ProjectDetail'; import {TABLE_IDS, FIELD_IDS} from './types'; ` --- ## 4. Table & Field ID Constants Derive constants directly from schema.md. Every table and field ID used by the extension gets a named constant. `js // types.js : derived from schema.md export const TABLE_IDS = { PROJECTS: 'tblXXXXXX', TASKS: 'tblYYYYYY', }; export const FIELD_IDS = { PROJECTS: { NAME: 'fldAAAAAA', STATUS: 'fldBBBBBB', DUE_DATE: 'fldCCCCCC', TASKS: 'fldDDDDDD', // linked record field }, TASKS: { TITLE: 'fldEEEEEE', ASSIGNEE: 'fldFFFFFF', }, }; // Field lists for useRecords calls (only the fields each view needs) export const PROJECT_LIST_FIELDS = [ FIELD_IDS.PROJECTS.NAME, FIELD_IDS.PROJECTS.STATUS, FIELD_IDS.PROJECTS.DUE_DATE, ]; export const PROJECT_DETAIL_FIELDS = Object.values(FIELD_IDS.PROJECTS); ` --- ## 5. Error Handling Every component that loads data must handle three states using standard HTML elements: 1. **Loading** : show a spinner or rely on Suspense 2. **Empty** : show a helpful message when no data exists 3. **Missing/deleted** : handle tables, fields, or records that no longer exist `js function ProjectView() { const base = useBase(); const table = base.getTableByIdIfExists(TABLE_IDS.PROJECTS); if (!table) { return ( <div className="p-4 text-gray-500 dark:text-gray-400"> The Projects table was not found. It may have been renamed or deleted. </div> ); } const records = useRecords(table, {fields: Object.values(FIELD_IDS.PROJECTS)}); if (records.length === 0) { return ( <div className="p-4 text-gray-500 dark:text-gray-400"> No projects found. Create a project in the base to get started. </div> ); } return (/* render */); } ` --- ## 6. Field Type Comparisons **Always compare field types using the FieldType enum, never raw strings.** String comparisons are fragile and won't catch typos at build time. `js import {FieldType} from '@airtable/blocks/interface/models'; // CORRECT : uses the enum if (field.type === FieldType.SINGLE_SELECT) { /* ... */ } if (field.type === FieldType.MULTIPLE_RECORD_LINKS) { /* ... */ } // WRONG : raw strings are fragile if (field.type === 'singleSelect') { /* ... */ } ` --- ## 7. Accessibility - Use semantic HTML elements: <nav>, <main>, <header>, <section>, <article>, <aside> - Add aria-label to interactive elements that lack visible text labels - Use <label> elements associated with inputs via htmlFor - Ensure all <button> elements have either text content or an aria-label - Use heading elements (<h1> through <h6>) for section titles with proper hierarchy --- ## 8. Library Usage Policy **Prefer established React libraries** over building complex UI from scratch. This produces more reliable, maintainable code. ### Recommended libraries | Need | Library | When to use | |------|---------|-------------| | Data tables | @tanstack/react-table | Sortable, filterable, paginated tables | | Date formatting | date-fns | Displaying dates in human-friendly formats | | Charts | recharts | Dashboards with bar/line/pie charts | | Drag-and-drop | @dnd-kit/core | Kanban boards, reorderable lists | | Complex forms | react-hook-form | Multi-step forms, complex validation | | Icons | @phosphor-icons/react | All icons : import with suffix (e.g., CaretDown) | | Markdown | marked | Rendering rich text / markdown content | ### Single-purpose component libraries are fine Libraries that solve a specific complex UI need (calendar, date picker, rich text editor, combobox, color picker) are encouraged : same rationale as @tanstack/react-table or recharts. Don't build complex interactive widgets from scratch when a well-maintained library exists. ### Do NOT add libraries for - **CSS/styling frameworks** (Bootstrap, Styled Components, etc.) : Tailwind is pre-configured by block init - **Full UI component suites** (Material UI, Chakra, Ant Design, Radix UI, etc.) : they bring their own styling system that conflicts with Tailwind and won't respect Airtable's design tokens or dark mode - **State management** (Redux, Zustand, etc.) : extensions are small enough for useState + useContext - **Routing** : extensions don't have URLs; use useState for view switching ### When adding a library - Add it to frontend/package.json dependencies - Run npm install --legacy-peer-deps in the frontend/ directory (needed for React 19 compatibility with some libraries) - Use the library's documented patterns : don't wrap it in custom abstractions - Import only what you need (tree-shaking compatible imports) --- ## 9. Dark Mode **Always support dark mode.** Airtable can render extensions in dark mode, and the Tailwind config includes dark mode tokens. - Use dark: Tailwind prefixes for all visual properties: `html <div className="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100"> ` - Test both modes visually : don't assume light mode only - Use semantic color classes from the Tailwind config (e.g., text-foreground, bg-surface) when available : these auto-adapt to dark mode --- ## 10. Resiliency Patterns ### Use getFieldIfExists() only `js // GOOD : returns null if field was deleted const field = table.getFieldIfExists('fldXXXXXX'); if (!field) return <div className="text-gray-500">Field not found</div>; // BAD : getFieldById and getFieldByName don't exist in Interface Extensions // const field = table.getFieldById('fldXXXXXX'); // const field = table.getFieldByName('Project Name'); ` ### Handle null cell values Every getCellValue call can return null. Always handle it: `js const name = record.getCellValue(FIELD_IDS.PROJECTS.NAME); <span>{name ?? '(untitled)'}</span> ` ### Check permissions before writes `js if (!table.hasPermissionToUpdateRecords()) { return ( <div className="p-4 text-gray-500 dark:text-gray-400"> You don't have permission to edit records. </div> ); } ` ### Use custom properties for configuration Use useCustomProperties for table and field configuration so the extension survives schema changes: `js import {useCustomProperties} from '@airtable/blocks/interface/ui'; function App() { const {properties} = useCustomProperties(); const tableId = properties.sourceTable; // ... } ` ### Centralize IDs Keep all table and field IDs in types.js. If the customer changes a field ID (rare but possible after field type changes), there's one place to update. --- # Part 5 : Common Transformations > A catalogue of canonical patterns for going from "what Omni gave you" to "what production needs". Pattern-match the user's request against this list; apply the canonical pattern. --- ## T1 : Static grid → circular / trigonometric layout **When:** 8 seats around a round table, clock faces, radial menus, network diagrams. **Omni output:** CSS grid (grid-cols-4) with seats in fixed positions. **Pattern:** Absolute positioning on a container, seats placed via polar coordinates. `js const SEATS_PER_TABLE = 8; const TABLE_RADIUS_PX = 110; // distance from center to seat center const SEAT_SIZE_PX = 56; function Table({tableNumber, guests}) { return ( <div className="relative w-[300px] h-[300px] mx-auto"> {/* Center label */} <div className="absolute inset-0 flex items-center justify-center"> <span className="text-lg font-semibold text-gray-700 dark:text-gray-200"> Table {tableNumber} </span> </div> {/* Seats around the circumference */} {Array.from({length: SEATS_PER_TABLE}).map((_, i) => { const angle = (i * 2 * Math.PI) / SEATS_PER_TABLE - Math.PI / 2; const x = 50 + (TABLE_RADIUS_PX / 150) * 100 * Math.cos(angle) / 2; const y = 50 + (TABLE_RADIUS_PX / 150) * 100 * Math.sin(angle) / 2; return ( <div key={i} className="absolute" style={{ left: ${x}%, top: ${y}%, width: SEAT_SIZE_PX, height: SEAT_SIZE_PX, transform: 'translate(-50%, -50%)', }} > <Seat seatNumber={i + 1} guest={guests[i]} /> </div> ); })} </div> ); } ` Key math: for N items around a circle, item i is at angle (i * 2π / N) from center. Subtract π/2 to start at the top (12 o'clock position) instead of 3 o'clock. --- ## T2 : Static list → drag & drop with swap **When:** Rearrange items by dragging; drop on empty slot moves, drop on occupied slot swaps. **Omni output:** Click to select, dropdown or form to assign position. **Pattern (simple cases):** HTML5 Drag and Drop API, native, no library. `js function Seat({record, position, onAssign, onSwap}) { const isOccupied = !!record; const handleDragStart = (e) => { if (!record) return; e.dataTransfer.setData('recordId', record.id); }; const handleDragOver = (e) => { e.preventDefault(); // Allows drop }; const handleDrop = (e) => { e.preventDefault(); const draggedId = e.dataTransfer.getData('recordId'); if (!draggedId || draggedId === record?.id) return; if (isOccupied) { onSwap(draggedId, record.id, position); } else { onAssign(draggedId, position); } }; return ( <div draggable={isOccupied} onDragStart={handleDragStart} onDragOver={handleDragOver} onDrop={handleDrop} className={isOccupied ? 'cursor-grab active:cursor-grabbing' : ''} > {/* ...seat UI... */} </div> ); } ` **Pattern (complex cases):** Use @dnd-kit/core for keyboard support, touch, accessibility, or multi-column flows (kanban). --- ## T3 : Blocking writes → optimistic UI **When:** Drag-and-drop, toggles, any UI where waiting on network feels sluggish. **Omni output:** await table.updateRecordAsync(...) inside the handler : UI freezes during the write. **Pattern:** Mirror Airtable state in local state, update optimistically, fire the mutation in the background, roll back on error. `js function useOptimisticAssignments(records, table) { // Build initial state from records const initial = useMemo(() => { const map = new Map(); records.forEach(r => { const tableNum = r.getCellValue(FIELD_IDS.TABLE_NUMBER); const seatNum = r.getCellValue(FIELD_IDS.SEAT_NUMBER); if (tableNum != null && seatNum != null) { map.set(r.id, {tableNum, seatNum}); } }); return map; }, [records]); const [overrides, setOverrides] = useState(new Map()); const get = useCallback((recordId) => { return overrides.get(recordId) ?? initial.get(recordId); }, [overrides, initial]); const assign = useCallback(async (recordId, tableNum, seatNum) => { // Optimistic setOverrides(prev => new Map(prev).set(recordId, {tableNum, seatNum})); try { if (!table.hasPermissionToUpdateRecords()) throw new Error('No permission'); await table.updateRecordAsync(recordId, { [FIELD_IDS.TABLE_NUMBER]: tableNum, [FIELD_IDS.SEAT_NUMBER]: seatNum, }); } catch (err) { // Rollback on failure setOverrides(prev => { const next = new Map(prev); next.delete(recordId); return next; }); console.error('Assignment failed', err); } }, [table]); return {get, assign}; } ` --- ## T4 : Single CRUD → batched mutations **When:** Swapping two records (two writes), bulk assigning many records, imports. **Omni output:** Loop of await table.updateRecordAsync(...) : slow and potentially rate-limited. **Pattern:** updateRecordsAsync(updates) accepts up to 50 records per call. Chunk larger operations. `js async function swapAssignments(recordAId, recordBId, posA, posB) { await table.updateRecordsAsync([ {id: recordAId, fields: {[FIELD_IDS.TABLE_NUMBER]: posB.tableNum, [FIELD_IDS.SEAT_NUMBER]: posB.seatNum}}, {id: recordBId, fields: {[FIELD_IDS.TABLE_NUMBER]: posA.tableNum, [FIELD_IDS.SEAT_NUMBER]: posA.seatNum}}, ]); } // Bulk import : chunk at 50 async function batchAssign(assignments) { const BATCH_SIZE = 50; for (let i = 0; i < assignments.length; i += BATCH_SIZE) { const chunk = assignments.slice(i, i + BATCH_SIZE); await table.updateRecordsAsync(chunk); } } ` Rate limit: max 15 batch calls per second. For very large operations, add a short delay between chunks. --- ## T5 : Hardcoded select options → dynamic from field config **When:** Filters, legends, dropdowns showing select or multi-select values. **Omni output:** Hardcoded array like ['Active', 'Pending', 'Done']. **Pattern:** Read from the field's options.choices array : survives new choices being added. `js const field = table.getFieldIfExists(FIELD_IDS.STATUS); const choices = field?.options?.choices ?? []; // Render as filter buttons {choices.map(choice => ( <button key={choice.id} onClick={() => setFilter(choice.name)} className="px-3 py-1 rounded-full text-sm" > {choice.name} </button> ))} ` See Part 2 §6 for mapping Airtable colors (blueBright, etc.) to Tailwind classes. --- ## T6 : No conditional indicators → badges & flags **When:** VIP badges, "needs attention" flags, priority markers. **Omni output:** Missing : Omni doesn't model conditional visual states unless prompted explicitly. **Pattern:** Conditional render with Tailwind badge classes, positioned absolutely over the main visual. `js function Seat({guest}) { const isVip = guest?.getCellValue(FIELD_IDS.VIP) === true; return ( <div className="relative w-14 h-14"> {/* Main seat content */} <img src={photoUrl} alt="" className="w-full h-full rounded-full" /> {/* VIP badge : absolutely positioned */} {isVip && ( <span className="absolute -top-1 -right-1 inline-flex items-center justify-center w-5 h-5 text-[10px] font-bold rounded-full bg-yellow-400 text-yellow-900 shadow"> ★ </span> )} </div> ); } ` --- ## T7 : No current-user awareness → personalized view **When:** "My tasks", "assigned to me", show-my-items toggle. **Omni output:** Shows everything; user has to filter manually. **Pattern:** useSession + filter by collaborator field. `js import {useSession} from '@airtable/blocks/interface/ui'; function MyTasks() { const session = useSession(); const currentUser = session.currentUser; const allRecords = useRecords(table, {fields: [FIELD_IDS.TITLE, FIELD_IDS.ASSIGNEE]}); const myRecords = useMemo(() => { if (!currentUser) return []; return allRecords.filter(r => { const assignee = r.getCellValue(FIELD_IDS.ASSIGNEE); return assignee?.id === currentUser.id; }); }, [allRecords, currentUser]); return (/* render myRecords */); } ` For multi-collaborator fields: assignees?.some(c => c.id === currentUser.id). --- ## T8 : Missing error states → resilient UI **When:** Every component that depends on a table, field, or records. **Omni output:** Usually shows blank or crashes silently if data is missing. **Pattern:** Explicit handling for 4 states: `js function ProjectList() { const base = useBase(); const table = base.getTableByIdIfExists(TABLE_IDS.PROJECTS); if (!table) { return <EmptyState message="Projects table not found. It may have been renamed or deleted." />; } const records = useRecords(table, {fields: PROJECT_LIST_FIELDS}); if (!table.hasPermissionToReadRecords?.()) { return <EmptyState message="You don't have access to this table." />; } if (records.length === 0) { return <EmptyState message="No projects yet. Create one to get started." />; } return (/* render records */); } function EmptyState({message}) { return ( <div className="p-6 text-center text-gray-500 dark:text-gray-400"> {message} </div> ); } ` --- ## T9 : Hardcoded layout dimensions → responsive **When:** Fixed pixel widths that break on narrow or wide viewports. **Omni output:** w-[800px] or grid-cols-5 regardless of viewport. **Pattern:** Use Tailwind breakpoints for adaptive layouts. `js // Instead of grid-cols-5 <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 xl:grid-cols-5 gap-6"> {tables.map(t => <Table key={t.id} {...t} />)} </div> ` For more control, use useViewport() from the SDK. --- ## T10 : Hardcoded values → custom properties **When:** The extension should be reusable across bases or configurable by the interface designer without code edits. **Omni output:** Hardcoded table IDs and field mappings. **Pattern:** useCustomProperties with a **module-level** getCustomProperties function (see Part 2 §2 : defining it inline causes infinite re-renders). `js // At module level, OUTSIDE the component function getCustomProperties(base) { return [ {key: 'guestTable', label: 'Guests table', type: 'table'}, {key: 'nameField', label: 'Name field', type: 'field', table: base.tables[0]}, ]; } function App() { const {customPropertyValueByKey} = useCustomProperties(getCustomProperties); const tableId = customPropertyValueByKey.guestTable?.id; // ... } ` --- ## Applying multiple transformations When the user asks for a big change (e.g., "make the wedding seating plan work with drag & drop"), decompose into transformations: 1. **T1** : circular seat layout (trigonometric placement) 2. **T2** : drag & drop between seats 3. **T3** : optimistic UI on assignment 4. **T4** : batched write for swap (2 records at once) 5. **T6** : VIP badge conditional render 6. **T8** : error states (table missing, no permission, no records) Apply them in this order: structural (T1), interactive (T2), performance/UX (T3, T4), polish (T6), resiliency (T8). Dark mode (dark:` variants) and field IDs are applied throughout, not as a separate pass.