@fiscozen/card

中文文档
3.0.15发布于 2026/10/23MITES Module近 30 天下载 2741

Design System Card component

原始使用文档
文档目录7 节
  1. Development
  2. Architecture
  3. Code Organization
  4. Key Concepts
  5. Internal Logic
  6. Design Decisions
  7. Known Limitations

@fiscozen/card

For usage documentation, see Storybook Documentation

Development

Architecture

The FzCard component is a layout container that groups related content and actions. It provides a consistent structure: optional header (title + slots), main content area, and optional footer (default action buttons or custom slot). It supports multiple background color variants, collapsible content with configurable default state, and optional info icon. All action buttons and the info icon use the same environment prop for visual context (backoffice vs frontoffice).

Key state:

  • isOpen: Ref controlling expanded/collapsed state when collapsible is true; initial value from defaultExpanded ?? false
  • normalizedColor: Computed mapping deprecated color values (e.g. aliceblue → blue) for internal styling
  • showContent: Computed — true when not collapsible or when expanded
  • isAlive: Computed — true when alwaysAlive or showContent; drives whether article/footer are in DOM (v-if)
  • existHeader: Computed — true when title or header/header-content slots are provided
  • atLeastOneButton: Computed — true when any of primary/secondary/tertiary action is set

Color and styling flow:

  • normalizedColor feeds backgroundColor and borderColor computed properties
  • Background/border use Tailwind classes: design tokens for default/blue/orange/purple/grey; semantic tokens for yellow (--semantic-warning-50) and red (--semantic-error-50)
  • Text color is always text-core-black for all variants

Code Organization

  • src/FzCard.vue: Single-file component; all logic and template in one place
  • src/types.ts: FzCardProps, FzCardColor, FzCardEnvironment, FzCardEvents, FzCardSlots, and internal action types
  • src/index.ts: Exports component and types

No subcomponents or utils/common modules; color mapping and layout logic live in the main component.

Key Concepts

Color Variants and Normalization

The color prop accepts: default, blue, orange, purple, grey, yellow, red, and deprecated aliceblue. All styling uses normalizedColor so that:

  • aliceblue is mapped to blue (same visual result)
  • A watch with immediate: true logs a deprecation warning when color === 'aliceblue'

Background and border classes are resolved in two computed properties (backgroundColor, borderColor) with a switch (normalizedColor.value) over the normalized value. Adding a new color requires adding a case in both computeds and extending FzCardColor in types.ts.

Collapsible and Content Visibility

  • When collapsible is false: content and footer are always visible; isAlive and showContent are true
  • When collapsible is true: header click toggles isOpen; showContent follows isOpen; article uses v-show="showContent" so it can be hidden without destroy
  • isAlive: When true, article and footer are rendered (v-if). When false (collapsible and collapsed and not alwaysAlive), article is not in DOM. So: alwaysAlive keeps content in DOM when collapsed; otherwise collapsed state removes article (and footer when no actions/slot)

Footer is shown only when (slots.footer || atLeastOneButton) && isAlive and v-show="showContent", so it hides with content when collapsed unless overridden by slot usage.

Action Buttons and Warnings

Primary, secondary, and tertiary actions are rendered in the default footer slot via FzContainer + FzButton / FzIconButton. Order in template: tertiary (icon), secondary, primary. On mount, the component warns if:

  • tertiaryAction is set without both primaryAction and secondaryAction
  • secondaryAction is set without primaryAction

These are guidance only; rendering still proceeds.

useMediaQuery from @fiscozen/composables and breakpoints from @fiscozen/style drive smOrSmaller. When true, footer has w-full on the container and flex-grow on secondary/primary buttons; footer layout uses justify-end when not smOrSmaller.

Internal Logic

Color Class Mapping

  • backgroundColor: default → bg-core-white; blue → bg-background-alice-blue; orange → bg-background-seashell; purple → bg-background-pale-purple; grey → bg-background-white-smoke; yellow → bg-semantic-warning-50; red → bg-semantic-error-50
  • borderColor: same keys → border-grey-100 (default), border-background-alice-blue, border-background-seashell, border-background-pale-purple, border-background-white-smoke, border-semantic-warning-50, border-semantic-error-50

All other colors (e.g. future tokens) require adding a case in both computeds and ensuring the Tailwind/semantic token exists in the design system.

Footer is rendered (v-if) when there is something to show and content is “alive”:

  • Condition: (slots.footer || atLeastOneButton) && isAlive
  • Visibility: v-show="showContent" so it hides when collapsible and collapsed
  • When only actions exist, default footer slot renders FzContainer with tertiary (FzIconButton), secondary (FzButton), primary (FzButton). Custom footer replaces this entirely via #footer.

defineExpose

Only toggleOpen is exposed; used for programmatic expand/collapse when collapsible is true.

Design Decisions

Why Normalize Color Instead of Removing aliceblue?

Keeping aliceblue in the type and normalizing to blue preserves backward compatibility. Consumers can migrate at their own pace while receiving a single deprecation warning. Removing it would be a breaking change.

Why v-if for Article/Footer and v-show for Visibility?

v-if="isAlive" controls whether the content block exists at all (e.g. when collapsed and not alwaysAlive). v-show="showContent" only hides the block visually when collapsible and collapsed but still “alive”. This allows optional DOM removal for performance while supporting alwaysAlive for stateful content that must stay mounted.

Why Action Warnings on Mount?

Tertiary/secondary without primary are allowed by the type system but are considered poor UX. The onMounted warnings guide consumers toward recommended usage without breaking existing code.

Known Limitations

  • No built-in loading/error state: Card does not provide loading or error UI; consumers can use slots or contentClass
  • Action order fixed: Tertiary, secondary, primary order is not configurable via prop
  • Single expand state: No accordion/group behavior; each card manages its own isOpen

版本与发布记录

@fiscozen/card 共发布 31 个版本,首次发布于 2024/06/21;过去 12 个月发布了 22 个版本。

版本发布日期距今
3.0.15latest2026/10/2322 天前
3.0.142026/10/2025 天前
3.0.132026/09/291 个月前
3.0.122026/09/142 个月前
3.0.112026/09/072 个月前
3.0.102026/08/043 个月前

其他发布通道:beta → 1.0.0-beta.3。

关于 @fiscozen/card 的常见问题

@fiscozen/card 是什么?

Design System Card component

如何安装 @fiscozen/card?

在项目目录运行 npm install @fiscozen/card,或使用 pnpm add / yarn add / bun add。它还需要宿主项目提供 peer 依赖:vue(^3.4.13)、tailwindcss(^3.4.1)、@fiscozen/icons(^1.0.8)。npm 7 及以上与 pnpm 8 及以上默认会自动安装必需的 peer 依赖,Yarn 需要手动安装。

@fiscozen/card 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/fiscozen__card 是否存在。

@fiscozen/card 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@fiscozen/card 可以商用吗?

@fiscozen/card 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@fiscozen/card 的下载量有多少?

根据 npm 官方下载统计,@fiscozen/card 在 2026/10/15 – 2026/11/13 这 30 天内被下载 2,741 次,日均约 91 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@fiscozen/card 还在维护吗?

最新版本 3.0.15 发布于 2026/10/23(22 天前);至今共发布 31 个版本,其中过去 12 个月发布了 22 个;首次发布于 2024/06/21。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。