[Today’s random Sourcerer profile: https://sourcerer.io/wteophilo]

One really important task for every web developer is to handle user input via forms and it can prove to be pretty hard to develop and maintain. Hopefully there are some libraries here to improve the way you handle them.

Schemas to the rescue!

Schemas are basically nothing more than a way to model data. You describe fields property of your data objects with meta information. It can be the type of each field, how it is stored, if it is required or optional, what will be the validation process for it…

Advantages of using schemas are numerous :

It provides a human-readable documentation for your data models and records.

You can implement a lot of algorithms on top of them (data validation, API generation)

You can expect better backend reliability by ensuring to have more coherent and homogeneous data sets (the major part of schema-less database will query faster on homogeneous data sets)

You can easily run some CI tests and maintainance with it. Those schemas won’t only help the full-stack dev but can also be of a good help to the sys-admin, or any person able to manipulate your data.

There are various specifications and formats for schemas. The most feature-complete specification for schemas in JSON is http://json-schema.org/

In this article, we will see how we can handle user input at a large scale in the front-end via form generation. We will then see how our data definition can be used on the backend to make the most of schemas in our architecture.

Vue-form-generator

This library will generate forms with a proprietary schema specification.

forms generated by schemas can be adapted easily to suit your designs and needs.

First of all, install vue-form-generator :

$ npm i --save vue-form-generator

Or

$ yarn add vue-form-generator

then include it in your Vue app :

Vue-form-generator is now configured, you’re nearly done !

Example case

Let’s assume that you want to build a user profile form, that handles user name, email, description, and additional links.

Write a component to handle your form :

And add a schema, for instance :

As you can see, the schema specification is not a popular standard, like JSON-schema. However, you are free to use your own algorithm to transform other standards to this one!

This newly created component will dynamically generate the form, according to the schema.

The generated form for the schema

One of the main advantages of using this tool to handle your schema is that all your data model declaration is completely detached from your code. So it can sort of help you to have the “M” of “MVC”, but without adding restriction on the way you code the rest of your web project.

You will be amazed to see how editing the form is easy : just edit the schema, and you’re done.

Field visibility

This library also provides a way to show or hide some fields. Just add a “visible” method in your schema, like this :

This method should return true or false, depending on the visibility of the field.

Using this feature on huge schemas has proven to be really useful for some projects I’ve made, as it makes forms way more ergonomic.

Data validation

This is another feature of vue-form-generator. You will be able to warn the user if he has not filled the password field as you expect him to :

Don’t forget to assign “validateAfterChanged” to true in the form options if you want the validator to run every time you change the value of an input!

Customization

And last, but not least, this library is pretty customizable : you can add all sorts of inputs and fields, and even code your own set of input components! The community behind it already started to create some additional ones, to handle more complex data structures or more ergonomic inputs.

For instance, if you want to handle telephone numbers, here is a custom field component for you : https://github.com/EducationLink/vue-tel-input

You can also find field components to handle source code, arrays or objects

React alternative

If you are more into React than Vue, similar libraries exists for this framework. You can have a look at mozilla-services/react-jsonschema-form as one viable alternative to vue-form-generator.

More from this library

You will find the documentation about vue-form-generator here. You can also toy with this jsfiddle. Try it, change the schema properties, invent your own!

What’s next?

Using schemas this way will make forms management easier. If you change the shape of you data, all forms you built with this philosophy will adapt. But hey, that is only the beginning ;D.

Data verification in the backend

As mentioned in the previous part, you can add a validator method to check if the data is correct. In case you want to prevent hackers to directly send malformed data to your backend, or if you have another client, it might be a good idea to reuse this validation part in your backend. In case you have a node backend, you can reuse the validation method as-is. If you use utility methods from a singleton in your validation method, you can swap this singleton to a more appropiate one in your server code.

An example of an error message that can be generated on a backend, and sent to a frontend

API generation

Admitting you want to build a CRUD API for your data. It can be a good idea to reuse schemas and to dynamically generate your routes.

To do so, you can add some more pieces of information about your routes in your schemas. For instance, putting a “url” property, and generating a full CRUD API endpoint, consisting of 4 routes (“GET/POST/PUT/DELETE”).

This will provide to your project a standardized way to manage your data. Unless you add some particular hooks for some routes, there will be no difference whatsoever for every data you need to handle.

Documentation

Once your schemas are set up, they provide a good way for you to document the data models of your project.

With the existing fields in every property, you will provide hints concerning the types of those properties, if they are required or not…

All information you put in your schema is valuable in a documentation, so take the best part of it! JSON format is already pretty readable, but you can also imagine to integrate them in a documentation viewer of your own conception.

You can generate API documentation automatically with schemas (Image from swagger UI)

Conclusion

This article is not about a guideline to follow without thinking. It is supposed to be inspirational for architectures you will build in the future.

If you write schemas with every feature specified above, a developer reading it will know which properties belongs to each data model, which one are required, how they are validated, on which routes they are used… You will be able to generate documentation for each data model, and even be able to generate a playground for the API, with generated forms.

Once data schemas changed, every part of your infrastructure and your documentation will adapt to the new shape of it.

The downsides of this architecture might be some huge side effects while editing schemas. That’s why, from my point of view, using this kind of architecture also require your project to have a consequent test suite. But hey, maybe you should write them anyway, shouldn’t you?

If you have any more ideas to use schemas on a web-based project, feel free to add a comment on this post!