Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted 11 months ago

React Contact Form Component

react
Ephraim•190
@ephraim-beltran
A solution to the Contact form challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


What are you most proud of, and what would you do differently next time?

The goal was to make the component as reusable/configurable as possible. While it is reusable(can just copy component directory and import to app), I still need to work on how to make it configurable such as adding more fields, configuring error messages, unified styling, etc.

What challenges did you encounter, and how did you overcome them?

The biggest challenge for me was triggering the input checking. I researched how to handle it, and most solutions require checking input on the onChange event. The pitfalls of input checking using the onChange event are as follows:

  • input will not be checked if the user skips the input element.
  • input syntax can't be checked properly while the user is typing
  • any syntax validity check will trigger on incomplete inputs (while the user is typing). I also found that I can check input using the onBlur event, where the user clicks out of the input box. This will solve most of the issues mentioned above except it will still allow users to skip an input and the error will not be triggered. Then I also found that inputs can be validated when the user submits the form. The onSubmit event is on the form wrapper. This solution allowed me to check the validity of the inputs in fewer lines of code. This solution, however, has brought on another issue: it reduces the modularity of the component. As my goal is to make the component as modular as possible, I opted to handle the submitted form using the browser-built-in JS form constructor Form(). By handling the form as such, new input fields can simply be created by creating another input element and the form wrapper will handle the entry on form submission. This however has a few problems. Some input elements (specifically radio buttons) will not show an entry if skipped therefore will not be iterated over for validity checking. The quick solution to this is to make the input required by adding the required property on the element. The input will now be "required" before form submission. The issues are now solved... Except, the required property solves all the issues that need solving: validity checking will be triggered on inputs with syntax requirements, skipped inputs will trigger an error, and form submission will trigger a validity check. So if it does all that, why apply it on only a single input when I can just use it on "all" the inputs with the required property? So further research helped me find out that React has an available onError event listener that will be triggered when elements with the required property have an invalid value. The required property gives me access to the built-in validity property of the input object. This allows me to determine the input error and define the error message. The onError event listener can be attached to each input element but React has a special type of event listener, onEventCaputure. onEventCapture will capture any Event that is triggered within the parent element that it is attached to. With that, the onErrorCapture is applied on the form wrapper, capturing all onError events on the nested input elements. This reduced the code repetition and increased the component's reusability. Additional input fields will dynamically have their validity checker when the required property is indicated.
Code
Loading...

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on Ephraim's solution.

Join our Discord community

Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!

Join our Discord

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit all CSS, SCSS and Less files in your repository.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.

How does the JavaScript validation report work?

When a solution is submitted, we use eslint to run an automated check on the JavaScript code.

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.