Collecting Responses

Since Formium is an API-first service, there are quite a few ways to gather responses (which we call submissions) to a single form. This guide we'll help you figure out which is right for your specific form and project.

Hosted Forms

Every form on Formium is hosted at a unique URL on forms.formium.io. You can find your form's hosted URL by either going to its Overview panel and looking at the Share your form card or by pressing the View button on the top right of the screen on any other panel (aside from the Editor). Hosted forms work exactly like forms on other traditional form building services you may have used such as Google Forms or Survey Monkey or TypeForm. The user experience is as follows:

1. You send your users to the form's URL (i.e. forms.formium.io/f/xxxxx).
2. Users fill out and submit the form
3. Responses are immediately stored on Formium (and are viewable in the Dashboard on the Results panel)

Now for the fun part...

Headless Forms

Instead of sending your users to https://forms.formium.io/f/xxxxx to fill out the form, you can keep them in your application or website by using Formium's API and helper libraries directly. And no, we're not talking about using an iframe like it's 2008, but instead using your very own code to render the form for yourself. Don't worry, this isn't as scary as it sounds.

How It Works

When you build a form on Formium with the drag-and-drop editor, you're not really building a form. You're actually generating an abstract data structure (a.k.a "schema") that represents your form. This big blob of data is an architectural blueprint that contains all the text, all the choices, all the conditional logic, all the itty-bitty details of your form. With our API, you can then use your form schemas in your application/website to natively render your forms as if they were hand-coded, using whatever programming language or framework you want to.

If this sounds like a lot, it totally is. However, unlike other "headless" CMS tools you may have used, we actually know exactly what you're going to do: You're going to render a form! It's going to have some inputs! It's probably going to have a submit button! So knowing all this and some more, we saved you a boat load of time and energy and built helper libraries to take care of the heavy lifting of fetching and interpreting your schemas and submitting responses. In fact, we actually use all of these packages on forms.formium.io to power all the "hosted" forms. So, in reality, when you make a hosted form, you're actually just making another headless form, but we're doing the headless stuff for you with our code. You're welcome.

Headless Architectures

Let's chat briefly about a few common "headless" architectures.

For security reasons, you form's schema isn't available on the public interwebz and requires an API key to access it. This constraint means you are going to need to fetch your form schema from the Formium API from a secure server-side environment at some point in your workflow.

Unfortunately, this next part is a bit of a "choose-your-own-adventure" situation. Where and when you fetch your schemas can differ greatly depending on the form, what frontend framework you use, how often your form updates, how long your app or site takes to rebuild, your hosting provider, your CI service, and your own personal preferences. To make things even more combinatorial (is that a even word?), not all hosting providers are created equal these days. Some providers such as Vercel can do special incremental static page regeneration for their Next.js framework that merges the concept of runtime and buildtime together, while other providers such as Netlify do not support the same features.

Anyways, there are a bunch of options here, but we think it ultimately boils down to whether you want to (or need to) fetch your form schema at runtime (per request) or buildtime (per deployment/build).

Fetch Schemas at Runtime

This strategy works by fetching your form's schema on every request from a server or serverless function. It's useful for apps that have have a LOT of forms where downloading all the schemas at once isn't possible. Or, for forms that need changes to be reflected immediately (like on the very next request). For example, forms.formium.io (the app that serves up the 15 quadrillion hosted forms on the platform) fetches your form schema at runtime because it would take an insanely long time to regenerate a static page for every form on everytime some users makes a change.

Fetch Schemas at Buildtime

The other approach is to fetch all your schemas during a build step and then trigger a full site rebuild whenever a change is made to a form in the Formium dashboard (using Formium's HTTP Webhook Workflow). The nice thing about this workflow is that your form schemas are immutable between deployments of your app, which makes debugging easier for in-app forms that rely on other code or app state.

Again, your specific workflow is going to depend your app or website.

So now what? Well, it certainly makes writing these friggin docs harder than it should be. As we just established, just giving you docs on our React library and JavaScript API client isn't really enough. Nor is it possible to write blanket React docs without also documenting hosting provider-specific features. Perhaps we'll have time to make some super cool form wizard / docs hybrid thingy one-day, but for now what we're going to do is show you a few ways to use Formium with the two most popular React.js frameworks (Next.js and Gatsby). Both guides come with detailed instructions on how to get your form schema into your app and how to use your own React components (which is why you're reading this).

Next.js

Source Code

Gatsby

Source Code