I still remember the days when I consistently glorify Meteor JS for all of my projects and event wrote a dedicated medium post titled 'Why I chose Meteor JS'. There was never a day since then I haven't thanked MeteorJS for all goodness it brought that delivers me to become a bit matured js developer. It lifted all the burden of steep learning curves of other frameworks and kept me away from the so called Javascript Fatigueness all around. And one of the biggest credit of my achievements has to go to aldeed:autoform that allows me and other MeteorJS developer to easily build forms in the simplest manner of writing a schema. I wouldn't dare to imagine how troublesome and terrible the tasks would be without it as my projects are mostly consists of deeply nested forms for database management and hospital information. Though, there were few times when I was stuck that I can't get customize the behavior of the library and can't get any way around to make the intended function to work. I would love to contribute to the aldeed:autoform project itself but I found the codebase is overwhelmingly long and complex (25k+ loc) which I don't even know where to begin with. I got the gist of this library and start to imagine how if I can rewrite everything frong scratch that allows me to use the same APIs as the origin autoform provides.
That's when I began to work on this tiny project that I dreamed to create. I love the idea of turning a schema of object to a tangible form that works versatily. So I start by planning what dependencies which will be involved in this project, I had to make sure that it will require the least amount of dependencies possible. After a bit of consideration, the choices comes to MithrilJS, LodashFP and BulmaCSS. These are the three essentials that will make this project work, no more and no less. Chances are most developers are well acquainted with the last two, but MithrilJS isn't new either, it's just a less popular vDom contender that deserves more spotlight. In term of package management, I'm not a big fan of npm, so I'd prefer CDN to serve the required dependencies. Three of them will takes less than 300kb over network and in storage so the size is still affordable.
If you haven't tried the library, I may suggest you to look at the (demo)[https://rikyperdana.github.io/autoForm] or (clone)[https://github.com/rikyperdana/autoForm] the project to your local machine.
The autoForm function expects an object like this:
m(autoForm({
id: 'formId', action: console.log,
schema: {
name: {type: String},
age: {type: Number}
}
}))
Pretty much like the quickForm method in aldeed:autoform right? Perhaps I should call this project a
quickForm remake instead. As I said before, you can use pretty much the same schema defenition as you
would do in the origin autoform. If you look into the autoForm.js you'll see inputTypes function which
will return options of type of field you want to set, they are hidden, readonly, datetime-local,
textarea, password, select, standard. I know the options provided are still pale compared to the
origin aldeed:autoform. I can't provide radio and checkbox input yet as their value has to be captured by
using jQuery or the likes and potentially may change the whole code base for that matter, so I
intentionally left them unfeatured for this moment. Yet, you can still use the select option and combine
it with the array field which will suffice to cover your need of checkbox.
As you may examine in the autoForm.js, I utilize recursion by numerous times that it will repeat rendering
any input fields recursively according to the depth of your defined schema. In one hospital software
project that I'm working on, the schema used may reach up to three level deep for drug documents. In order
to allow us to insert and update the document by the same form, this autoForm function may accept doc
object in the argument which will render the given values for each respective fields. And the different
behavior of radio and checkbox html input field than the other type of fields made it much more harder
for me to adjust the update functionality into the function.
Amidst the limitation of this autoForm function, there are few subtle differences that may give you more
versatility in building a dynamic form. In example, on the number and date type field, you may access
minMax function with callbacks which allows you to dynamically adjust the minimum or maximum value based
on current state of any particular fields. Same goes to the select field type which will give you the
similar callbacks that allow you to set the selection options dynamically according to certain conditions
or other particular fields. There's also the excluded field type which will allow you to show a field in
the form that the value in it shall not be submitted in the document. The readonly and hidden field type
is still pretty much similar to the origin.
After a month and another couple of weeks, through lots of trial and error, now we have a javascript function in 200+ line of codes in length that pretty much embody the purpose of automatic form generation based on document schema. This small autoForm function is in no way to compete with or replace the well known, complex, and full-fledged origin autoform that aldeed created and I don't have the intention too. But if you're looking for a smaller alternative which you may modify yourself up to your needs, then this function may appeal to you.