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