Test whether the SDK produces a stable structural hash (sh) across multi-step, dynamic, and conditional form patterns
The SDK computes a structural hash (sh) from a form's field names, types, required attributes, button text, and method. This hash is cached per form_id for the page session so that multi-step or dynamic forms don't produce different hashes as the DOM changes.
Goal: Verify the hash stays stable across all common real-world patterns. Each fixture below uses a different technical approach that websites use in the wild. Watch the SDK's sh value in Preview — it should remain the same across interactions within a single form.
What goes into the hash: field names (normalized), field types, required status, submit button text, form method. Field values and visibility do NOT affect the hash.
Different coding approaches websites use to implement multi-step/wizard forms. The SDK should produce the same sh across all steps.
All fields exist in the DOM at page load. Steps are shown/hidden via CSS display:none class toggling. This is what WordPress, Gravity Forms, and most simple wizards use.
Only the current step's fields exist in the DOM. Advancing replaces the form body via innerHTML. Common in HubSpot, enterprise portals, and server-rendered wizards.
Each step's fields are built programmatically via document.createElement. Previous step fields are removed from the DOM entirely. Common in SPA frameworks (React, Vue).
The entire <form> element is destroyed and recreated for each step. Some WordPress plugins and Marketo do this. Tests whether the cache survives form element replacement.
Traditional server-rendered multi-step forms where each step is a separate page load. The SDK's in-memory fingerprint cache is wiped on every navigation, so each step computes a fresh hash from whatever fields are on that page.
Fields: firstName, lastName, email, phone. This is the first page load — the SDK will fingerprint these 4 fields.
EXPECT CHANGEFields: company, jobTitle, industry, companySize. Full page reload — cache is gone, hash computed from these 4 different fields.
EXPECT CHANGEFields: interests, timeline, message, prefs checkboxes. Third page load, third distinct sh value. All 3 share the same form ID.
Fields that appear, disappear, or change based on user interaction. Tests whether the hash stays stable when the visible form structure changes.
Conditional fields are always in the DOM but shown/hidden via CSS based on a dropdown selection. Most common conditional field pattern (Gravity Forms, WPForms, Formidable).
EXPECT STABLEConditional fields are actually added to and removed from the DOM via appendChild/removeChild. Used by React/Vue conditional rendering and some advanced form builders.
"Add another" pattern where users can add/remove groups of fields (e.g., multiple phone numbers, addresses). Fields are cloned from a template. Common in CRMs, applications, surveys.
STRESS TESTFields appear one-by-one as the user fills them in. Each interaction reveals the next field via DOM insertion. Used by Typeform-style forms and conversational UIs.
STRESS TEST