Discuss about Autoform for React

Autoform is great, but it’s tied to simple-schema and meteor. Now react is popular as ui component layer, but it’s not good to use it with autoform with hard works of adapting blaze to react and blablabla.
I previously released a package for building react form easily, but it’s too simple to be extended to support recursive structures(group, array…), thus it can’t fit with simple-schema easily. With this experience, now I’m building another form package with the mind to design it supporting recursive structures. Now a test version is available with few docs, and IMO, it works well, achieving the design goals and easier to extend with looser architecture.
But, this is not a release post. I learned we need to dig the requirements and use cases more deeply to discover the true face the package should be, so I want to get some voice from the society.

  • Do you need some autoform-like package for react ?
  • Do you know (use) any other solutions? If they solve your problem well? If not, why?
  • How do you expect to use this package?
  • Are you willing to help extend it?
  • Any other idea, suggestions, or whatever you want to say…

Thanks for supports!


As a new-ish Meteor + React developer I don’t have the experience to give a solid reply, but I’d like to say that blaze autoform really helped me through together an MVP quickly.
I’d love a similar package for React, it would help with prototyping immensely.

You could try this Simple-React-Form.

Yes, I have noticed this package before. It’s a good try but IMO too much affected by the design of simple-schema. I can’t run its example, so I don’t know if it supports recursive structures. On the other hand, for such a long time it only supports material-ui, this is unfortunate, if the author had got more people involved into the dev, it may be better now. In general, it’s good, but not satisfies my needs yet.

Folks from vazco.eu just released as alpha this autoform like npm package for React with Simple Schema. https://github.com/vazco/uniforms
Looks pretty cool, but have not tried it out yet.

Just to clarify what we are asking, here’s what autoform does for the uninititated

Simply by defining a scheme with validation rules (validation rules are provided automatically for data type and isRequired settings) then creating a form with autoForm (a single line of code) and you get all this for free:

  • An autogenerated form that uses bootstrap3 classes (extensible via custom template definitions).
  • Appropriate HTML5 fields for all keys in your collection schema.
  • A submit button that gathers the entered values and inserts them into your collection (alternatively, can use a set of hooks for more granular control).
  • Form validation based on the schema attached to your collection. By default the form is validated when the user submits. If anything is invalid, the form is continually re-validated on keyup (throttled) as the user fixes the issues.
  • Default validation error messages that appear under the fields, and can be customized and translated.
1 Like

oh, this project is very, very cool. the apis and structure designs are beautiful. I really hope it was released one year before. it’s indeed the react version of autoform. some possible problems in my view:

  • too big: I think new users should read a batch of docs to grab it. it’s the same case for old autoform.
  • bound to simple-schema: simple-schema is not a plain standard schema, and is tied to meteor.
  • this package itself is only for meteor.

with the steps of meteor towards the big js eco-system, I think new coming package should consider it twice to build on npm, not atmosphere.

A complex project can do many things, but may be more difficult to learn, use, extend and maintain.
I am thinking of building a simplified project which try to grab the core 80% use case and try to make it easy to learn and use.
I will listed some of the features, do you think these are ok, and do you think some others not-listed here are important but missed?

  • simple schema: no, not aldeed:simple-schema, I mean, the form should use a much simpler schema than simple schema. by keeping unknown of the value type, the fields of a schema can be heavily reduced.
  • generate form with one-line.
  • self-management: no need to hook the values and validation data, all are managed by the form and offered in onSubmit callback.
  • it should not be hard to extend styles and field types.

Hey @zhaoyao91 !

Currently I’m the main developer of uniforms. API is designed to make it both easy and customisable if needed. It is possible to generate self-managed form with one-line and all data in onSubmit callback - the following line is taken from documentation:

<AutoForm schema={PostSchema} onSubmit={doc => console.log(doc)} />

Currently there’s no special styling features, so you can rely on CSS classes. Also, it’s quite easy to create custom field type.

Yes, current version is strictly Meteor package, becouse aldeed’s SimpleSchema is commonly used in Meteor community and it provides validation and error messages out of box, but it wouldn’t be hard to use different schemas.

What do you mean by a plain standard schema?

Hi, thanks for your great work.
If I continue a new meteor project, I would be glad to try this package, it’s really good, but may be not much stable by now as it’s new here, not a problem, I’m sure it’ll be successful and popular.
I am just worried about that many great packages like this one will be limited used because of dependence of SimpleSchema and Meteor.
By saying plain standard schema, I mean a schema is just a js object with basic types(object, array, string, number, simple function), this will help transformation, serialization and universal use. SimpleSchema is thus not a plain schema, it should be built as an instance of a js class.

Integration with plain schemas like this one:

  name: String,
  age:  Number

to describe field types is not a problem (<AutoField /> actually does it), but what about validation? In that case you have to validate it on your own, but it is not a problem, right?

I have released rf-form. Although both rf-form and uniforms can build react form automatically, they have many different design goals. I hope we can talk and share the experiences, thoughts an ideas about the common parts for this domain.

I was playing with trying to transform a simple-schema into other formats/objects for use with other packages… I got a functional proof of concept here:

But I have since, switched to

and my fork, implementing bootstrap4

Here’s a use case that I’ve been struggling to reconcile with Autoform: a recurring date form. I’ve built it manually since I don’t see support for dynamic forms that change type or number of fields at the middle and end of the form based on inputs at the top of the form. Form layout and options are as follows:

Event name
Event type
Event dollar amount
Radio for single or recurring
IF recurring, show radio for week, month, or year
–> IF week, show weekday picker, and add/remove more weekday instances in demand
–> IF month, show date picker and add/remove more instances in demand
–> IF year, show month picker AND date picker, and add/remove instances in demand
IF recurring, show Radio to enable skipping instances.
—> IF skipping is activated, show picker for number of skips - every 2 weeks, every 3 months, etc. Units match from previous selection (week, month, year)

I want to hide unused options to keep the form in its simplest state at all times, reducing user confusion. The form should seem to walk the user through the options instead of showing everything when it is opened.

It’s a static form in the sense that I’m not using it in different contexts in the app, so maybe Autoform isn’t even the right tool for this case. But I wanted the schema and validation features that are built in to autoform, without having to write the validation routines myself.


You can probably use the form data in the context and ask for a field’s value and use that information to display a different component.

Thanks, I’ll give that a try!

Did you get a chance to try this? What was the outcome? I am interested to know as it’s something we need every now and then.

Hey, I’ve been trying to work with Uniforms but have really been struggling to wrap my head around some of the specifics of the implementation. radekmie has been really helpful and patient with me on github, but i don’t want to pollute his repo’s issues with my questions, so hopefully you guys could help offer some insight.

has anybody gotten into customizing forms or manipulating the autoform component? I guess I don’t fully grasp how you can make specific changes to a particular field without altering the schema.

for example, if i wanted to change the SubmitField, i can pass a new component into the “submitField” prop on the AutoForm component. However, if i’d like to do the same for the title field or description field… i don’t seem to understand how to handle that. My problem is i have a pretty large form, and i only want to modify or change one or two fields.

this seems like such a great library, i hope someone can help me understand some of the basics.

I really encourage you to join our Gitter room - it will be easier to communicate either with me or other people using uniforms.

If you want to use a different field only for few ones, you can use AutoFields component. Example:

<AutoForm {...props}>
    <AutoFields fields={['a', 'b']} />
    <MyCustomField name="c" />
    <TextField name="d" placeholder="test" />
1 Like