表单 开发 文档
表单 开发 文档
表单是在 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."
}
}支持的字段类型
支持的字段类型包括:
textemailphoneurltextareanumberselectradiocheckboxcheckboxesdatefilehidden
字段集合应与操作工作流保持一致。收集业务不使用的数据的表单会给访客和内部团队带来摩擦。
表单定义示例
技术评审应该能够快速推理出模型:
{
"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>决策规则:
- 固定嵌入 -> 模板拥有的一个稳定工作流
- 基于字段的嵌入 -> 可重用组件,作者可选择工作流
提交流程
高层次流程:
- 表单在中心定义
- 通过组件将其嵌入页面
- 访客提交结构化输入
- 运行验证和提交处理
- 提交被存储并路由到相关业务工作流
概念上:
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/这使一个工作流在多个转化触点间保持一致。