If you’ve had your crack at building react front end apps , or you've simply worked with react for a while, you’ve most likely crossed a design that includes a form. A form meant to receive the users input, whether it be text, content, number or a selection, you want their information for the form.
A seasoned well versed react user would say to handle these forms we should install Formilk or Yup most likely. I myself have become a fan and couldn't agree more. But something came to mind, how would it look like if we had schemas?? Could this be the new direction ? After diving deep into the web i came to two new questions. Is Yup just for Formilk? Or should Yup only be used with Formlik? My answer is no. Here’s why.
Schemas reason ??
Lately i’ve been working a lot with API’s, and having to parse a lot of data transforming and code transliteration. One thing in common with all of these was the lack of schema in those learning process. I had to get my brain sweaty and do some manual mapping of data, duplicating code, ect.
A schema can be seen as a container for a structure. A structure describes how a certain field will be laid out and formatted. By prepping your schema for react you will become of new and better ways to parse your data or code transliteration. Trying things we never have, turns inexperience into knowledge and wisdom for future people in need.
Experimenting with Schema
Honestly i had many doubts before beginning the process. The very fact that i had to think long and hard made it seem as if it would not be a good fit right from the get go. It wasn’t standard routine. It was a different approach that could prove to be a terrible decision or a fun great new discovery for myself. But if what better way to truly find out then to attempt it myself. What is there to fear? Getting my hands and brains dirty and growing from it is what i love about the learning process.
My tested application will have to do with sending and receiving data. I’ll use the data to the API endpoints using the schema.
I’ll start with sending data to the API end point. Let’s say our endpoints are accepting the following schema.
THE routine approach would be to get the form values using Formlik and do an HTTP call to fetch the request.
It worked!! It does work.In this example the schema based is redundant and inefficient. To make it more precise and tested we can add a data constraint and assume the form values aren't matched with the API’s schema.
Non-schema based approach uses the ES6 property renaming feature and the other one leverages Yup’s features to rename the property as well as create an object. The ES6 approach was always an option for the schema based one as well it was done to illustrate it in plain approach. This way there would be no confusion and nothing mixed with the clarification.
Now that we have tested sending an HTTP request tot he API, we can try to use the schema in receiving the request. Mismatching API schema is unavoidable so to make it more realistic we will also include mismatched API data in the upcoming example.
Non-schema based approach
It happened again. Once again the ES6 property renaming feature on our first approach and on the second approach repeated themselves and took Yups same method. However it did not use the casting method right away. Renaming an object ket can be done a number of way but the approach you are most comfortable should be the one you use in this case.
We have just finished both our approach in receiving and sending data to the API using the two different approaches. One where we schemed a plan and tackled it and where we did not.
This was an attempt to rethink our conventional way of thinking and approaching this schema based style. I personally enjoy the schema-based approached; it allowed for a better object field composition and being able to express how the structure should be shaped. I did try to rethink Yup as an object based schema builder and not just for its validation which came from Formilk.
I am aware that there are a lot fo things we can explore together on this schema-based approach. There are many flaws and not many conventional examples to provide guidance. But when we rethink something outside of the normal flow it opens new doors; new knowledge, new opportunities, experience and personal growth. This is just the beginning.
React makes it painless to create interactive UIs. Design simple views for each state in your application, and React…