feat(badge): unify badge interface to support array values in DescriptionCard and DataTable to render multiple badges by IzumiSy · Pull Request #278 · tailor-platform/app-shell

IzumiSy · 2026-05-22T07:18:32Z

Summary

In typical AppShell applications, DataTable is used on list pages and DescriptionCard on detail pages — users navigate from a table row to its detail view. To provide a consistent badge experience across this common pattern, this PR unifies badge rendering into a shared BadgeList component that both DataTable and DescriptionCard use, with support for array values and overflow handling (maxVisible + hover popover).

Usage

// DescriptionCard — array badges with maxVisible
<DescriptionCard
  fields={[{
    key: "tags",
    type: "badge",
    meta: {
      badgeVariantMap: { urgent: "error", fragile: "warning" },
      maxVisible: 3,
    },
  }]}
  data={{ tags: ["urgent", "fragile", "heavy", "oversized"] }}
/>

// DataTable — badge column with array accessor
column({
  ...infer("tags"),
  type: "badge",
  typeOptions: {
    badgeVariantMap: { Premium: "warning", Office: "outline-info" },
    maxVisible: 2,
  },
})

Screenshots

DescriptionCard with multiple badges:

DataTable with multiple badges:

Changes

BadgeList component (`badge-list.tsx`)

Consolidate badge-utils.ts into badge-list.tsx as single source of truth
Shared BadgeList component renders one or more badges with overflow popover
Overflow popover opens on hover (openOnHover)
Exports: BadgeVariant, BadgeOptions, BadgeListProps, BadgeList, resolveBadgeVariant, resolveBadgeLabel

Array badge support

DescriptionCard badge field now accepts array values (string[])
DataTable badge column accepts string[] from accessor
Single values continue to work as before (fully backward-compatible)

Unified badge interface

Shared BadgeOptions interface used by both DataTable and DescriptionCard
resolveBadgeVariant() / resolveBadgeLabel() shared utilities
Default badge variant unified to "outline-neutral" across both DataTable and DescriptionCard (previously DataTable used "neutral" and DescriptionCard used "outline-neutral")
DataTable's BadgeCellOptions extends BadgeOptions with maxVisible
Keep BadgeVariantType as a deprecated alias for backward compatibility
DataTable renderBadge now correctly shows — placeholder for empty arrays (consistent with DescriptionCard)

inferColumns() fix

Remove default render from infer() return value so type renderers take priority
Previously, column({ ...infer("field"), type: "badge" }) would use the generic formatValue render instead of the badge renderer
Add renderText fallback for boolean (✓/✗), Date (toLocaleDateString), and object (JSON.stringify) to avoid regressions
Columns without explicit type or render now display — for null/empty values (aligns with typed-column behavior)

DataTable demo

Add tags field with multiple badges and maxVisible: 2 to product table
Convert status column from custom render to declarative type: "badge" + typeOptions

Tests

badge-list.test.tsx: 18 tests covering utilities and component behavior
data-table.test.tsx: Added tests for renderText fallback (boolean, Date, object), array badge, and empty array placeholder
field-helpers.test.ts: Updated expectations for removed render property

pkg-pr-new · 2026-05-22T07:36:25Z

Open in StackBlitz

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

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

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

commit: 92e2900

IzumiSy · 2026-05-22T09:23:23Z

/review

github-actions

Generated by API Design Review for issue #278

…interface - DescriptionCard badge field now accepts array values, rendering multiple badges - Extract shared BadgeVariant type and BadgeOptions interface into badge-utils.ts - DataTable's BadgeCellOptions now extends shared BadgeOptions - Add badgeLabelMap and defaultBadgeVariant to DescriptionCard FieldMeta - Deprecate BadgeVariantType in favor of shared BadgeVariant - Add resolveBadgeVariant/resolveBadgeLabel shared utilities - Add example of array badge usage in vite-app

- Add maxVisible option to FieldMeta for badge fields - Overflow badges shown in a popover on click with full Badge UI - +N trigger is a simple text element with hover highlight (no dot) - Add popover interaction test

- Extend badge accessor type to accept string[] in addition to primitives - renderBadge handles arrays with multiple Badge rendering - Add maxVisible + Popover overflow (same pattern as DescriptionCard) - Update type test: badge accessor now allows arrays - Add rendering tests for multi-badge and maxVisible in DataTable

- Merge badge-utils.ts into badge-list.tsx as single source of truth - Remove default render from inferColumns() to fix type renderer priority - Add renderText fallback for boolean/Date/object values - Add openOnHover to BadgeList overflow popover - Add tags badge column to DataTable demo (multiple badges + maxVisible) - Convert status column from custom render to type: badge - Add comprehensive tests for BadgeList, renderText fallback, and field-helpers

- renderBadge now returns placeholder for empty arrays (consistent with DescriptionCard) - Align default badge variant to 'outline-neutral' across DataTable and DescriptionCard - Remove redundant BadgeVariant override in DescriptionCard field-renderers - Add changeset

… test - renderBadge now filters array items and returns placeholder when all values are null or empty strings - Add tests for [null, null] and ["", ""] badge column cases - Change field-renderers test to use user.hover instead of user.click to match the openOnHover popover behavior

erickteowarang · 2026-05-25T02:24:22Z

 */
 function BadgeFieldRenderer({ field }: { field: ResolvedField }) {
-  if (isEmpty(field.value)) {
+  const values = Array.isArray(field.value)


Can we make this into an if/else function instead? Nested ternaries are a bit hard to read/understand

Agreed. I guess nested ternaries should be prohibied by linting.

I would like to update oxlint rules to prevent nested ternaries, so let me work on it in the next PR.

erickteowarang · 2026-05-25T02:26:53Z

+  resolveLabel: resolveLabelProp,
+  badgeClassName,
+}: BadgeListProps): React.ReactNode {
+  const values = Array.isArray(value) ? value : [value];


From an API design perspective, wouldn't it make more sense to force value to always be an array even if there's only one? That way we don't have to check the variable type and consistently enforce it as an array through TS

Good point to raise.

The reason I went with T | T[] is to optimize for caller ergonomics — most usages will pass a single value, and forcing callers to wrap it as an array adds repeated boilerplate at every call site. Internal type consistency is preserved by normalizing on the first line, so the rest of the component still operates on T[] with full type safety.

This also matches how React's own APIs behave — children, style, and similar props all accept T | T[] and normalize internally, which I think sets a reasonable precedent for forgiving input shapes in shared components.

Given AppShell is consumed across many surfaces — including by AI coding agents that often forget the [x] wrap and incur an extra type-error-then-fix round trip — I'd lean on this pattern to minimize friction at call sites.

Yeah fair enough, as long as coding agents consistently follow this pattern I don't see an issue :)

erickteowarang · 2026-05-25T02:28:34Z

  if (isEmpty(value)) return PLACEHOLDER;
+  if (typeof value === "boolean") return value ? "✓" : "✗";
+  if (value instanceof Date) return value.toLocaleDateString();
+  if (typeof value === "object") return JSON.stringify(value);


Is this intentional? The value can look pretty strange with this

I also think it might more sense to convert this to a Switch case command for readability

Here is the mixture of multiple types of comparison using typeof and instanceof, so can we really make everything in one switch?

I think that'll be fine, because switch evaluates on a boolean, this can be like:

function renderText(value: unknown): ReactNode { switch (true) { case isEmpty(value): return PLACEHOLDER; case typeof value === "boolean": return value ? "✓" : "✗"; case value instanceof Date: return value.toLocaleDateString(); case typeof value === "object": return JSON.stringify(value); default: return String(value); } }

I'm not super fussed though, it's only 4 conditions so it's not too bad right now, but if we want to add more conditions it might be useful.

More concerned about stringifying objects, maybe it should throw an error instead?

siwtch (true) looks stylish, but I remember it disables type narrowing, doesn't it? I don't like that if so.

More concerned about stringifying objects, maybe it should throw an error instead?

I cannot ensure if throwing errors there does not break any of the current projects that use AppShell, so best not touch that for backward behaviour compatibility. Showing data to users is not harmful if that's just raw JSON.

siwtch (true) looks stylish, but I remember it disables type narrowing, doesn't it? I don't like that if so.

Ah, I probably didn't know we can do it now? Then, let's go with switch one!

microsoft/TypeScript#53681

Ah, I probably didn't know we can do it now? Then, let's go with switch one!

Yeah since TS version 5.4 it's possible, but like I said, there's only 4 conditions so I'm okay if we don't do it haha.

I cannot ensure if throwing errors there does not break any of the current projects that use AppShell, so best not touch that for backward behaviour compatibility. Showing data to users is not harmful if that's just raw JSON.

Ah right, yeah I guess in that case it's fine, we should probably start enforcing it in the future though.

Refactored renderText to use switch(true) in 92e2900.

erickteowarang · 2026-05-25T02:29:33Z

-    options?.badgeVariantMap?.[key] ?? options?.defaultBadgeVariant ?? "neutral";
-  const label = options?.badgeLabelMap?.[key] ?? key;
-  return <Badge variant={variant}>{label}</Badge>;
+  const items = Array.isArray(value) ? value : value != null ? [value] : [];


Same as below, I think we should enforce this to remain an array so we don't constantly transform/re-transform it

Maybe #278 (comment) will answer this too?

…ability

erickteowarang · 2026-05-26T01:21:57Z

+    case isEmpty(value):
+      return PLACEHOLDER;
+    case typeof value === "boolean":
+      return value ? "✓" : "✗";


ふと思ったんですが、ここは✓✕より○✕の方が日本っぽくないですか？ 😄

たしかにそうですね。しかし、このbooleanのfallback rendererって使ってる人いない可能性もあるので、撤廃してもいい可能性あります。

IzumiSy changed the title ~~feat(badge): support array values in DescriptionCard and unify badge interface~~ feat(badge): unify badge interface to support array values in DescriptionCard and DataTable to render multiple badges May 22, 2026

IzumiSy self-assigned this May 22, 2026

github-actions Bot reviewed May 22, 2026

View reviewed changes

Comment thread packages/core/src/components/data-table/cell-renderers.tsx Outdated

Comment thread packages/core/src/components/description-card/field-renderers.test.tsx Outdated

IzumiSy added 6 commits May 25, 2026 11:02

feat(badge): add maxVisible with popover overflow for array badges

0411476

- Add maxVisible option to FieldMeta for badge fields - Overflow badges shown in a popover on click with full Badge UI - +N trigger is a simple text element with hover highlight (no dot) - Add popover interaction test

Remove redundunt accessor prop

412c160

IzumiSy force-pushed the feat/badge-array-support branch from c967c63 to 412c160 Compare May 25, 2026 02:02

IzumiSy requested review from davedc, erickteowarang, interacsean and victornguyen May 25, 2026 02:14

erickteowarang reviewed May 25, 2026

View reviewed changes

refactor(cell-renderers): convert renderText to switch(true) for read…

92e2900

…ability

IzumiSy requested a review from erickteowarang May 25, 2026 08:43

erickteowarang reviewed May 26, 2026

View reviewed changes

erickteowarang approved these changes May 26, 2026

View reviewed changes

IzumiSy merged commit 2197c3f into main May 26, 2026
5 checks passed

IzumiSy deleted the feat/badge-array-support branch May 26, 2026 01:37

Uh oh!

Conversation

IzumiSy commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Usage

Screenshots

Changes

BadgeList component (badge-list.tsx)

Array badge support

Unified badge interface

inferColumns() fix

DataTable demo

Tests

Uh oh!

pkg-pr-new Bot commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IzumiSy commented May 22, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erickteowarang May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

IzumiSy commented May 22, 2026 •

edited

Loading

BadgeList component (`badge-list.tsx`)

pkg-pr-new Bot commented May 22, 2026 •

edited

Loading

erickteowarang May 25, 2026 •

edited

Loading