Last updated:
To display and execute forms, Formcentric requires client-side runtime files. These provide the form logic, widget components, and translations.
How these files are served and loaded depends on your chosen integration method:
Choose the delivery path that matches your setup.
The split client.js is a small entry module that imports client.core.js. The shared runtime loads widgets from components/ and languages from locales/. Publish both files and these directories from the same package build with their relative directory structure unchanged.
The default entry URL /form/client.js may be redirected. Relative imports are resolved against the final response URL. The entry module and dynamically loaded widgets then import the same client.core.js; using a different entry URL does not create a second shared runtime instance.
For deployments under a subpath, an unprefixed entry URL can remain in the embed configuration if the server redirects it to the complete runtime directory under the deployment prefix. The embed does not need to bypass this entry redirect.
Keep the URLs of the shared runtime and chunks consistent. If only individual imports are rewritten, or if the shared runtime is redirected while widgets import it via a different URL, duplicate module instances can occur. For versioned deployments, publish the complete runtime directory under a version prefix. For stable URLs, configure cache revalidation for all runtime files.
| Hosting Example | Configuration |
| A customer website embeds forms from a different delivery domain | Supported if the delivery server allows cross-origin module requests for the entry module, shared runtime, and nested chunks. The website's hostname does not change the relative module URLs. |
A CDN redirects /client/latest/client.js to /client/v42/client.js |
Supported. Publish client.core.js, components/, and locales/ alongside the final entry URL under /client/v42/. |
| A reverse proxy maps stored assets to a public prefix | Provide the complete directory structure under this prefix. Internal rewrites preserve the public URLs. Redirects of the entry module are supported if the complete runtime directory is located at the final destination. |
formapp.js is the fully bundled UMD compatibility entry point for existing integrations. The file includes all bundled widgets and languages and does not require runtime chunk directories. Older wrappers continue to load this file as a classic script.
The wrapper selects the runtime as follows:
formappUrl, the wrapper loads /form/client.js from the base URL with type="module". Cross-origin module requests require CORS as well as a JavaScript Content-Type. By default, they do not send cross-origin credentials.formappUrl / data-fc-formapp-url selects the full classic formapp.js and is always loaded as a classic script, even with non-descriptive CMS media URLs. This option must not point to an ES module.formappUrl is deprecated for new cloud integrations; omitting it uses the default split runtime. Existing classic integrations remain supported.The Client SDK (@formcentric/client), as well as the React and Vue packages, each include the form runtime and import it dynamically when embedding a form. They do not load client.js from Delivery and do not accept formappUrl. The consuming application's bundler processes the included runtime along with its widget and language imports, generating its own chunk names and references. The React and Vue packages only require the client package for its theme assets.
Publish the complete application build, including all generated chunks. Configure the bundler's asset base URL or public path for the deployment directory or CDN. Do not separately load another unprocessed runtime alongside the bundled runtime. If the runtime is excluded from bundling and delivered unchanged, the requirements for direct delivery above apply.
