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 and taking your feedback seriously We may even follow up with you for more information.
How to participate
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.
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:
How did you build your form?
static HTML, form submissions via AJAX
static HTML, form submissions not via AJAX
What do you use your form for?
Did you run into any issues building or submitting to your form?
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!
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.
@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
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.
I use the form as a super simple contact form (name, email, message) on a create-react-app.
YES, I ran into issues.
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.
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
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
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