feat(DataTable): add type-aware cell renderers on Column

[erickteowarang]

Summary

• Adds type (text / number / money / date / badge / link) and a typeOptions field to Column<TRow>. When type is set, the cell is rendered automatically from accessor(row) (or row[id] when accessor is omitted), eliminating the inline boilerplate that every list table re-implements for currency, date, and badge formatting.
• render is always optional and continues to win when both are present, so the existing escape hatch is preserved.
• Empty values (null / undefined / "") render a muted — placeholder uniformly across types; link cells render plain text when typeOptions.href returns nullish.

Type safety

Column<TRow> is a discriminated union keyed off type (ColumnBase<TRow> & ColumnTypeBranch<TRow>). typeOptions narrows per branch to a dedicated interface (NumberCellOptions, MoneyCellOptions<TRow>, DateCellOptions, BadgeCellOptions, LinkCellOptions<TRow>), and the following become compile errors rather than runtime no-ops:

// ❌ badgeVariantMap is not a money option
column({ type: "money", accessor: (r) => r.total, typeOptions: { badgeVariantMap: {} } });

// ❌ link columns must provide typeOptions.href
column({ type: "link", accessor: (r) => r.title });

// ❌ text columns reject typeOptions entirely
column({ type: "text", accessor: (r) => r.title, typeOptions: { locale: "en-US" } });

Three @ts-expect-error assertions are checked in via the test suite to lock these guarantees in.

render lives on ColumnBase (not per-branch) so callback contextual typing still works on the common column({ ...inferred, render: (row) => ... }) spread pattern — row infers without annotation. ColumnBase and ColumnTypeBranch are both exported publicly so api-extractor rolls them into the dist .d.ts.

Accessor return type is also narrowed per branch

accessor lives on each branch (not on ColumnBase) so each typed renderer can constrain what the column produces. Returning an array or a plain object from a typed accessor is a compile error instead of silently rendering [object Object] or a stringified list:

// ❌ text accessor cannot return an array
column({ type: "text", accessor: (r) => r.tags });

// ❌ money accessor cannot return an object
column({ type: "money", accessor: (r) => r.priceDetail });

Per-branch return types:

type	accessor return type
(omitted)	unknown — pairs with render
text	string | number | boolean | bigint | null | undefined
number	number | null | undefined
money	number | null | undefined
date	Date | string | number | null | undefined
badge	string | number | boolean | null | undefined
link	string | number | boolean | null | undefined

Why this is part of a three-PR series

This is 1 / 3 in a series porting patterns from a downstream consumer's ReconciliationList into the platform DataTable. The remaining two PRs add align and truncate on Column as independent, mechanical changes — landing as separate PRs to keep each diff small and reviewable.

Notes for reviewers

• New module: packages/core/src/components/data-table/cell-renderers.tsx. Pure functions per type; renderTypedCell dispatches once per cell in DataTable.Body and narrows col.typeOptions per-branch via switch (col.type) — no casts.
• money formatting accepts a string or (row) => string for currency, mirroring the currencyKey pattern in the source component but in a typesafe way. Falls back to "USD" if the resolved currency code is invalid (Intl throws otherwise).
• link cells use react-router's Link (already re-exported from app-shell) so SPA navigation is preserved.
• Docs at docs/components/data-table.md get:
  • Updated Column reference (shared fields + per-type fields tables) reflecting the discriminated-union shape
  • New "Cell types" section listing each type's value handling and options interface
  • New "Adding a typed column" recipes section walking through each built-in type, the override-with-render escape hatch, and how to layer type on top of inferColumns

Public type additions

Type	Purpose
ColumnCellType	"text" | "number" | "money" | "date" | "badge" | "link"
ColumnBase<TRow>	Shared column fields
ColumnTypeBranch<TRow>	Per-type branches with narrowed typeOptions and accessor
NumberCellOptions	Options for type: "number"
MoneyCellOptions<TRow>	Options for type: "money" (currency accepts a function)
DateCellOptions	Options for type: "date"
BadgeCellOptions	Options for type: "badge"
LinkCellOptions<TRow>	Options for type: "link" (href required)
BadgeVariant	Variant union accepted by <Badge>

Test plan

• pnpm --filter @tailor-platform/app-shell type-check — clean
• pnpm --filter @tailor-platform/app-shell test — 992 passed (was 974; +18 new cases: per-type rendering, accessor fallback, custom-render override, and 4 type-level @ts-expect-error assertions including array/object accessor rejection per typed branch)
• pnpm --filter @tailor-platform/app-shell lint — clean
• pnpm --filter @tailor-platform/app-shell build — dist .d.ts includes ColumnBase and ColumnTypeBranch
• pnpm -r type-check — workspace clean (nextjs + vite demos typecheck unchanged against narrowed accessor)
• pnpm fmt:check — clean across 342 files
• Reviewer smoke-test: drop column({ label, type: "money", accessor }) into the data-table demo and confirm the column renders without a render prop

🤖 Generated with Claude Code

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@tailor-platform/app-shell@247

npm i https://pkg.pr.new/@tailor-platform/app-shell-sdk-plugin@247

npm i https://pkg.pr.new/@tailor-platform/app-shell-vite-plugin@247

commit: d7179c0

[IzumiSy]

/review

[github-actions]

Generated by API Design Review for issue #247

[IzumiSy]

@copilot does badge type render multiple badges when the given data is array?

[Copilot]

@copilot does badge type render multiple badges when the given data is array?

No — currently badge renders a single <Badge> only. If the value is an array, it gets stringified (e.g. ['a','b'] becomes "a,b") and shown as one badge.

[IzumiSy]

@erickteowarang Can you cover the corner case like what happens when the data is array/object? I guess there should be some limitation or adoption for data structure. Supporting array will be needed anyway (I remember that I have been reported that DescriptionCard cannot renders the multiple badges, but users wanted that)

[erickteowarang]

@erickteowarang Can you cover the corner case like what happens when the data is array/object? I guess there should be some limitation or adoption for data structure. Supporting array will be needed anyway (I remember that I have been reported that DescriptionCard cannot renders the multiple badges, but users wanted that)

Do you mean if someone sends in an array of like, badges to the columns?

It won't crash, but it will result in text not appearing properly (e.g if you send in an array of string to the text type, it'll return a,b, and an object will be [object Object])

I can add some defensive coding for that use case (e.g just render array/object data as a placeholder string). Future array support should probably be done in a separate PR though.

[erickteowarang]

@IzumiSy Updated now to make it ultra specific for each column type.

I think this makes it safer (will fail on compile time) and more extendable (so if Badge accepts an array in the future, we can just adjust the type)

[IzumiSy]

LGTM!