Tell us about your experience with Forms!

:wave: I’m Jen. Maybe you’ve seen me around the forum. Maybe we’ve even worked on your site’s form together!

We’re interested in hearing how our Forms feature is working for you. If you spend a few minutes filling out our smol survey, we’ll thank you by showering you with emojis :bouquet: and taking your feedback seriously :mag_right: We may even follow up with you for more information.

How to participate

  1. First, fill out the poll in question 1. Note that you can only vote once, but you may change your vote if you accidentally choose the wrong option.

  2. Then, copy/paste questions 2-4 into a comment and add your responses. If you’d prefer to share your feedback over DM, please note that in a comment or send me a message and I’ll get back to you. Without further ado:

The survey

  1. How did you build your form?
  • static HTML, form submissions via AJAX
  • static HTML, form submissions not via AJAX
  • Javascript-rendered form, form submissions via AJAX
  • Javascript-rendered form, form submissions not via AJAX

0 voters

  1. What do you use your form for?

  2. Did you run into any issues building or submitting to your form?

  3. If you ran into issues, how did you solve them? Did you write your own Netlify Function to process form submissions, integrate another form service into your site, or something else?

We look forward to your responses in the comments!

Hey @jen! :wave:t2:

I think the survey is a little tough to answer from a technical perspective. Specifically looking at build frameworks that implement the React renderToServer -> Client Hydrate methods, technically the form, when rendered on a device that has Javascript disabled, is a pure static HTML form that doesn’t use AJAX. When rendered in a browser that is using Javascript, it’s now a Javascript-rendered form and submits using AJAX. That duality is sort of the beauty of the renderToServer/Hydrate methodology, but presents a particularly tough situation for Netlify Forms as a product. I think lots of folks having trouble trying to “just get it working”, muchless getting into the weeds of how/why is why I ended up making https://github.com/jon-fm/react-ssg-netlify-forms - but even that only helps React-based SSG folks (Gatsby, Next.js, maybe Redwood?)… and even then it’s a tad clunky :stuck_out_tongue:.
I’m not sure how all the Vue stuff works or if it supports a similar server-to-client-hydrate system, but if it does they’re going to be in the same boat.


Jon

1 Like

Okay wow, lots to unpack there! Thanks for schooling me @jonsully- gotta dig into the hydration stuff more, seems like this has a nice set of posts linked at the top if anyone else is curious:

@jen glad to be of help! For what it’s worth, I actually just got around to writing about this in depth. The mid section of this article kind of gets to the meat

But the whole premise is… difficult. These SSGs aren’t made to accommodate code changes between when the build exports out the static content and when the application actually runs in a browser. They expect the code to be the same on both sides. React’s docs talk about the hydrate() method here but a key note:

React expects that the rendered content is identical between the server and the client. It can patch up differences

And ultimately, Netlify injecting the hidden input in the static HTML and pulling the netlify or data-netlify="true" attributes off the <form> are both “differences” that React patches. And let me tell you; React patches. They’re very “this could happen” in the docs, but in all instances I’ve seen, React will patch things in the client tree within milliseconds of hydrating.

Their suggestion for when code needs to be different on the client vs. server is:

If you intentionally need to render something different on the server and the client, you can do a two-pass rendering. Components that render something different on the client can read a state variable like this.state.isClient , which you can set to true in componentDidMount() . This way the initial render pass will render the same content as the server, avoiding mismatches, but an additional pass will happen synchronously right after hydration. Note that this approach will make your components slower because they have to render twice, so use it with caution.

Which is essentially exactly what that package I wrote does and that’s really the only way it works. Looking here:

I’m basically checking if we’re in the build time or runtime and if it’s build time, display the Netlify Forms tags. If it’s runtime, instead display a normal form and prepare to POST the form-name field manually because the hidden form-name input Netlify generates will get snipped by React when it hydrates

Hope some of that helps! It’s a head-scratcher :stuck_out_tongue:


Jon

  1. What do you use your form for?

A contact page on my website

  1. Did you run into any issues building or submitting to your form?

They stopped working after enabling the --minify building option for Hugo site generator. More details here.

  1. If you ran into issues, how did you solve them? Did you write your own Netlify Function to process form submissions, integrate another form service into your site, or something else?

I solved it by try and error and after @jen mentioning the site generator. My form is as simple as it can be, so the issue appears to be between hugo’s minified result and Netlify form processing.

1 Like

My previous experience using forms was great. However when building what I thought was a basic copy and paste version of the same form, a simple registration form, I couldn’t get the form to be recognised by Netlify. I eventually found the Forms debugging FAQ page that explained about the action field breaking the process if it points to a full url.
My comment would be, if that is a known feature why is it not in the standard forms documentation page, or at the very least a link from there to the debugging FAQ’s.

I have now corrected my action and form is working as expected.

1 Like

Thanks so much to everyone who’s chimed in, your feedback is super helpful!

@simon77 this might have been added since you were working on your form, but we do now have a sentence about what your action path should look like: Forms setup | Netlify Docs

  1. I use the form as a super simple contact form (name, email, message) on a create-react-app.

  2. YES, I ran into issues.

  3. Your documentation is bad. Im referring to this:

issue 1) “In any HTML file in your site folder” - No. It goes in /public/index.html, right under the opening body tag.

issue 2) " Add a hidden form-name field to your JSX form" - This implies you need 2 forms, a JSX form and a HTML form in a file called contact.html. It implies this in several places. The fact is, you do not.

issue 3) name=“form-name”. This is LITERAL. Dont replace “form-name” with for example “my-super-awesome-form”. It wont work.

issue 4) The example and the example zip file are not relevant to a real react project and wouldnt work in a real react project.

issue 5) The youtube video results for “netlify react form” are horrid. There is flat out bad info in most of them. I found exactly one video that cleared it all up for me, and it only had like 85 views. Here: Implement Netlify Forms in React App - The CORRECT Way - YouTube

You guys should make training videos. Love netlify, just needs polish on the documentation.

Oh also, one of the icons in your icon lib is wrong. :slight_smile:

Hey Jason! thanks for giving us your feedback on Netlify forms, and of course it’s not great for us to hear you didn’t have the experience you were expecting. A few notes -

  • the blog post you quoted (not documentation, which is anything found here: docs.netlify.com) is a few years old, and our technology does move pretty fast. It’s possible what was quoted there is out of date. We do ask that you consider our docs the single source of truth for this kind of thing! The docs are constantly being kept up to date and go through much more rigourous vetting than blog posts do :+1:

  • if you see docs inconsistencies please do point them out to us - do be mindful that we work very hard to make our documentation world class, so finding a way to phrase this in a neutral tone is appreciated :slight_smile:

  • we don’t actually do any quality control for youtube videos about our platform from 3rd party providers - I wish we had the staffing where that would be possible! But alas, that is unlikely to be in our future. The most reliable sources of video based content are here:

which are two official content channels, and of course the independent offerings from people who are actually Netlify employees, such as Jason’s Learn With Jason site:

Again, sorry to hear you didn’t have the experience we all wish you’d had, but referring to the docs and finding a way to phrase things neutrally is a great approach in the future :smiley: