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:

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:

// 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:

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:

// 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:

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:

// 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:

// Typical Omni output
const table = base.getTableByName('Guests');

Gap: getTableByName throws if the table is missing. No graceful degradation.

Fix pattern:

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:

// Typical Omni output — crashes if Name is blank
<span>{record.getCellValue('Name').toUpperCase()}</span>

Fix pattern: Always guard with ?. or ?? fallback:

<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:

import {Check, Star} from '@phosphor-icons/react';

9. Dark mode

Omni almost never generates dark mode classes. Everything is light-only:

// Typical Omni output
<div className="bg-white text-gray-900">

Fix pattern: Add dark: variants to every color class:

<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

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

// 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:

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.

// 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:

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:

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

// 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:

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.

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.

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.

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.

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

Common patterns

"My items" toggle — let users switch between "My Items" and "All Items":

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:

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:

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:

// 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

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):

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:

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:

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:

// 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

Writing Cell Values

Use table.updateRecordAsync(recordId, fields) or table.createRecordAsync(fields). The fields object maps field IDs to values.

Write formats by FieldType

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.

// 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:

// 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

3. Import Order

Group imports in this order, separated by blank lines:

// 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.

// 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

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.

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

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:

  <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

// 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:

const name = record.getCellValue(FIELD_IDS.PROJECTS.NAME);
<span>{name ?? '(untitled)'}</span>

Check permissions before writes

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:

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.

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.

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.

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.

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.

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.

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.

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:

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.

// 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).

// 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.