Every time I read the documentation of libraries that promise to make the development of forms easier, I get deeply frustrated. I can't believe someone looks to those libraries and thinks they really improve the development experience.
Some of the reasons would include the counterintuitiveness of those APIs, the amount of code a developer still needs to write, and the difficulties of reusing that code. But the root cause behind all these reasons is the same. The lack of audacity at the moment those libraries were designed. Yes, in my opinion, those libraries seem to start solving the problem ahead of the desired starting point. The moment in which "we can be crazy" or the "what if we tried a completely different thing" moment. Those libraries have internalized the boringness involved in developing a form, so they can't find any way to overcome it.
At some point in my career, I started to dream with two HTML improvements that would make me very, very, very happy.
The first one regards the form control elements. That is,
<textarea>. My desire was that they had a property called
validations. It will accept an Array of objects, each containing the attributes
isValid - a function returning a Boolean value - and
errorMessage, a String to be shown in the case of
isValid returns false. This attribute would allow us to run several validations against a form control and set a specific message for each possible error.
The second improvement target is the
<form> element. For Single Page Applications, it would be great to use properties like
errorMessage. On submit success, the form would show the success message on a toast. If the request failed, a banner would display the error message with a retry button at the top of the form.
Translating my dream to HTML, we'd have something like this:
For three years, my letters to Santa Claus banged for that dream come true. So at the end of 2020, convinced that Santa would ignore me one more time, I decided to put my hands on it and make it happen by myself.
The form creation experience was the true motivation behind Taslonic. I created it to set me free from the ordinary work and focus on the extraordinary one. No one deserves to waste hours of life implementing the same form use cases, again and again, every time the application needs another form. Besides wasting time, the repetitive implementation of those cases - feedbacks for success, error, and processing - leads to uncountable inconsistencies in the use of the application. Sometimes a developer implements them one way, sometimes another developer makes them another way. Not to say the times some of those use cases are forgotten. Who hasn't ever stood before a never-ending loading even after a request failure?
Explore this example of a newsletter form made with Taslonic.
Here is all I needed to code while creating this form:
- Email address validation
- Request fired on submit
- Data reset on submit success
Below, everything the form brings to me without making me write one single line of code:
- Shows an asterisk aside required field labels
- Shows the error message for invalid fields only after the user blurs them at least once.
- Shows the error messages for all invalid fields on submit if the user tries to submit the form without filling them correctly.
- Replaces the submit button label with a loader during the request and returns it to the original state when the request is complete.
- Disables the submit button during the request processing to avoid multiple submissions.
- Fires a toast containing a custom message on submit success.
- Shows a banner at the top of the form containing a button that allows users to resend data on submit error.
They represent seven use cases that I didn't need to implement and, consequently, test. Are you curious to see the code? Here are some links:
If you liked what you have seen here, consider starring Taslonic's repository on Github to help more developers know it and waste less time creating forms.