表单 开发 文档

表单 开发 文档

表单是在 FaceFlow 页面和组件中嵌入的集中管理提交模型。

它们允许技术团队定义可重用的询问和接收工作流,这些工作流可以以缓存安全的方式呈现、在提交时处理,并作为结构化的业务资产进行管理。

核心职责

表单负责:

  • 可重用的表单定义
  • 字段模式
  • 运行时渲染
  • 验证和提交处理
  • 通知路由
  • 条目捕获
  • 在多个页面或组件之间重用

表单应清晰地建模一个业务工作流。如果一个定义试图处理多个不相关的工作流,操作和报告都会变得脆弱。

核心表单模型

表单通常结合以下内容:

  • 稳定的表单标识
  • 字段模式
  • 展示配置
  • 成功与通知行为
  • 提交处理规则
  • 条目存储与管理

在实践中,表单层既定义访客可以提交的内容,也定义业务如何接收和处理该提交。

概念上:

{
  "name": "enterprise-demo-request",
  "fields": [
    { "name": "full_name", "type": "text", "required": true },
    { "name": "work_email", "type": "email", "required": true },
    { "name": "company", "type": "text", "required": true },
    { "name": "message", "type": "textarea", "required": false }
  ],
  "settings": {
    "submitText": "Request demo",
    "successMessage": "Thanks. Our team will contact you shortly."
  }
}

支持的字段类型

支持的字段类型包括:

  • text
  • email
  • phone
  • url
  • textarea
  • number
  • select
  • radio
  • checkbox
  • checkboxes
  • date
  • file
  • hidden

字段集合应与操作工作流保持一致。收集业务不使用的数据的表单会给访客和内部团队带来摩擦。

表单定义示例

技术评审应该能够快速推理出模型:

{
  "name": "contact-sales",
  "fields": [
    { "name": "full_name", "type": "text", "required": true },
    { "name": "work_email", "type": "email", "required": true },
    { "name": "company", "type": "text", "required": true },
    { "name": "team_size", "type": "select", "required": false }
  ],
  "settings": {
    "submitText": "Contact sales",
    "successMessage": "Thank you. We will reply shortly."
  }
}

这使得在将表单嵌入任何地方之前可以讨论字段契约、必需数据以及工作流归属。

运行时嵌入

表单通常通过组件嵌入页面区块。

一个常见的嵌入标记是:

<div data-form-embed="contact-form"></div>

示例区块:

<section class="contact-section">
  <div class="section-copy">
    <h2>Talk to our team</h2>
    <p>Tell us about your goals and timeline.</p>
  </div>

  <div data-form-embed="enterprise-demo-request"></div>
</section>

这允许页面结构保持可重用,同时实际的表单模型保持集中管理。

固定嵌入 与 基于字段的嵌入

有两种常见的嵌入模式。

当模板应始终呈现一个特定表单时,使用固定的托管表单 id:

<div data-form-embed="enterprise-demo-request"></div>

当组件公开一个 formSelect 字段并且作者在创作时应选择托管表单时,使用基于字段的嵌入:

<div data-form-embed="{contactForm}"></div>

决策规则:

  • 固定嵌入 -> 模板拥有的一个稳定工作流
  • 基于字段的嵌入 -> 可重用组件,作者可选择工作流

提交流程

高层次流程:

  1. 表单在中心定义
  2. 通过组件将其嵌入页面
  3. 访客提交结构化输入
  4. 运行验证和提交处理
  5. 提交被存储并路由到相关业务工作流

概念上:

Component render
  -> runtime form HTML
  -> visitor submits
  -> validation
  -> entry saved
  -> notification routed
  -> success response returned

集成模式

清晰的集成路径是:

Form definition
-> Component embed via formSelect or explicit data-form-embed marker
-> Page composition
-> runtime rendering and submission handling

这保持了表单行为的集中管理,同时允许页面和组件保持可重用。

通知与条目

表单不仅仅是前端捕获。它们还支持提交的操作端。

典型功能包括:

  • 通知路由
  • 提交条目管理
  • 条目审核
  • 导出工作流

技术团队应审查完整的操作路径,而不仅仅是表单在页面上的视觉呈现。

字段契约 指南

保持字段契约足够窄,以便工作流保持明确。

典型模式:

  • 联系或演示请求 -> text, email, textarea, 可选 select
  • 资格审核流程 -> text, email, select, number
  • 上传辅助的接收 -> 仅在业务确实处理附件时添加 file

要优先选择一个清晰的工作流契约,而不是试图捕获每种可能线索路径的过大表单。

重用策略

良好的表单设计通常倾向于重用。

如果多个页面共享相同的业务工作流,它们通常应共享相同的表单模型。

这会改进:

  • 可维护性
  • 字段契约的一致性
  • 通知行为
  • 报告和下游处理

示例:

Homepage demo CTA
Pricing page demo CTA
Enterprise solution page CTA
  -> same demo-request Form

如果工作流相同,表单通常应该相同。

技术指南

  • 围绕一个业务工作流建模每个表单
  • 在工作流相同的页面之间重用同一个表单定义
  • 保持字段要求与实际操作需求一致
  • 当共享模型可行时,避免页面特定的重复
  • 一起审查渲染、提交、通知和条目处理
  • 在发布前测试真实的提交路径

反模式

避免:

  • 当工作流相同时为每个页面创建新表单
  • 将不相关的线索路径组合到一个过大的表单中
  • 收集业务从不使用的可选数据
  • 在页面模板中硬编码表单标记而不是嵌入托管模型
  • 只审查视觉输出而忽略操作路径

示例构建模式

Component:
  lead-form

Embed:
  <div data-form-embed="contact-sales"></div>

Pages:
  /pricing/
  /enterprise/
  /contact/

这使一个工作流在多个转化触点间保持一致。

相关