🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português
🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português

Documentation developpeur Form

Documentation developpeur Form

Les Forms sont des modeles de soumission geres centralement et embarques dans les Pages et Components FaceFlow.

Ils permettent aux equipes techniques de definir des workflows reutilisables de demande et d'intake qui peuvent etre rendus de maniere compatible cache, traites au moment de la soumission et geres comme des actifs metier structures.

Responsabilite centrale

Un Form est responsable de :

  • definitions de formulaires reutilisables
  • schema de champs
  • rendu runtime
  • validation et traitement des soumissions
  • routage des notifications
  • capture des entrees
  • reutilisation sur plusieurs Pages ou Components

Un Form doit modeliser clairement un workflow metier. Si une definition essaie de gerer plusieurs workflows sans lien, les operations et le reporting deviennent plus faibles.

Modele central de Form

Un Form combine generalement :

  • une identite stable de formulaire
  • un schema de champs
  • une configuration de presentation
  • un comportement de succes et de notification
  • des regles de traitement des soumissions
  • le stockage et la gestion des entrees

En pratique, la couche Form definit a la fois ce que le visiteur peut soumettre et la maniere dont l'entreprise recoit et traite cette soumission.

Conceptuellement :

{
  "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."
  }
}

Types de champs pris en charge

Les types de champs pris en charge incluent :

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

Les ensembles de champs doivent rester alignes avec le workflow operationnel. Un Form qui collecte des donnees que l'entreprise n'utilise pas cree de la friction pour les visiteurs comme pour les equipes internes.

Exemple de definition de Form

Une revue technique doit pouvoir raisonner vite sur le modele :

{
  "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."
  }
}

Cela permet de discuter du contrat de champs, des donnees obligatoires et de la propriete du workflow avant que le Form soit embarque ou que ce soit.

Embedding runtime

Les Forms sont generalement embarques dans des sections de page via des Components.

Un marqueur d'embed courant est :

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

Exemple de section :

<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>

Cela permet a la structure de page de rester reutilisable tout en gardant le modele de formulaire reel gere centralement.

Embeds fixes vs pilotes par champ

Il existe deux patterns d'embed courants.

Utilisez un id de Form gere fixe quand le template doit toujours rendre un Form specifique :

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

Utilisez un embed pilote par champ quand un Component expose un champ formSelect et que les auteurs doivent choisir le Form gere au moment de l'edition :

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

Regle de decision :

  • embed fixe -> un workflow stable possede par le template
  • embed pilote par champ -> Component reutilisable avec workflow selectionnable par l'auteur

Flux de soumission

Au plus haut niveau :

  1. le Form est defini centralement
  2. il est embarque dans une Page via un Component
  3. le visiteur soumet une entree structuree
  4. la validation et le traitement de soumission s'executent
  5. la soumission est stockee et routee vers le workflow metier concerne

Conceptuellement :

rendu du component
  -> HTML du form au runtime
  -> le visiteur soumet
  -> validation
  -> entree enregistree
  -> notification routee
  -> reponse de succes retournee

Pattern d'integration

Le chemin d'integration propre est :

definition du form
-> embed dans un component via formSelect ou marqueur data-form-embed explicite
-> composition de page
-> rendu runtime et traitement de soumission

Cela garde le comportement du formulaire centralise tout en permettant aux Pages et Components de rester reutilisables.

Notifications et entrees

Les Forms ne servent pas seulement a la capture front-end. Ils prennent aussi en charge la partie operationnelle des soumissions.

Capacites typiques :

  • routage des notifications
  • gestion des entrees de soumission
  • revue des entrees
  • workflows d'export

Les equipes techniques doivent revoir le chemin operationnel complet, pas seulement verifier que le formulaire se rend visuellement sur la page.

Conseils de contrat de champs

Gardez le contrat de champs assez etroit pour que le workflow reste evident.

Patterns typiques :

  • contact ou demande de demo -> text, email, textarea, select optionnel
  • workflow de qualification -> text, email, select, number
  • intake avec upload -> ajoutez file seulement si l'entreprise traite vraiment les pieces jointes

Preferez un contrat de workflow clair a un formulaire surdimensionne qui essaie de capturer toutes les trajectoires de lead.

Strategie de reutilisation

Une bonne conception de Form privilegie en general la reutilisation.

Si plusieurs Pages partagent le meme workflow metier, elles doivent generalement partager le meme modele de Form.

Cela ameliore :

  • la maintenabilite
  • la coherence des contrats de champs
  • le comportement des notifications
  • le reporting et le traitement aval

Exemple :

CTA de demo sur la homepage
CTA de demo sur la page pricing
CTA de demo sur la page enterprise solution
  -> meme Form demo-request

Si le workflow est le meme, le Form doit en general etre le meme.

Conseils techniques

  • modelez chaque Form autour d'un workflow metier unique
  • reutilisez une meme definition de form sur les Pages lorsque le workflow est identique
  • gardez les exigences de champs alignees sur les vrais besoins operationnels
  • evitez la duplication specifique a une page lorsqu'un modele partage suffit
  • revoyez ensemble rendu, soumission, notification et gestion des entrees
  • testez le vrai chemin de soumission avant publication

Anti-patterns

Evitez :

  • de creer un nouveau Form pour chaque Page alors que le workflow est identique
  • de combiner des parcours de leads sans rapport dans un seul Form surdimensionne
  • de collecter des donnees optionnelles que l'entreprise n'utilise jamais
  • de coder en dur du markup de form dans les templates de page au lieu d'embarquer le modele gere
  • de ne revoir que la sortie visuelle en ignorant le chemin operationnel

Exemple de pattern de construction

Component:
  lead-form

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

Pages:
  /pricing/
  /enterprise/
  /contact/

Cela garde un workflow coherent sur plusieurs surfaces de conversion.