I really like autoform and I’ve actually been trying to port something like it to PHP for use in Laravel. It’s definitely more complicated since we use MySQL but I also think it’s really not all that crazy difficult.
Aldeed - I really love Autoform! One of the things personally about it that I find a bit hard is actually navigating the documentation mostly because there’s so much of it and it’s split between projects and websites (and I’m one of those people that likes to be handed the solution i’m looking for on a silver platter lol). I think if someone is like me they might think it’s harder to do certain things in autoform than it really is (if that makes sense). I really want to write some extra tutorials on it to help you when I have time! But…maybe even linking to good tutorials and good real life examples at the top of the docs would help? I’m shy about contributing but maybe I’ll do a pull request. Web Tempest used to have tutorial, I have the code for it here: https://github.com/sgelbart/meteor-js-autoform-example. I think https://medium.com/meteor-js/how-to-build-web-apps-ultra-fast-with-meteor-iron-scaffolding-and-automatic-form-generation-11734eda8e67#.dr78oimkd is a good tutorial too and https://themeteorchef.com/tutorials/building-complex-forms… there’s also a sad thread about it here Advanced autoform examples 
I’m happy to accept documentation PRs. (You might have to ping me beyond just submitting the PR since I’m still working through backlogs on that repo.)
I’ve wanted to combine and improve all the docs on a separate doc website for years. I even half-started it twice. It’s just a lot of work and I haven’t fit it into scare time. If anyone is interested in helping, I can invite you to a Slack I set up where I’m trying to organize contributors and get help to move things along faster.
I’ll add that the official demo app (http://autoform.meteorapp.com) is sort of documentation and playground in one, but also does not cover everything in a newbie “tutorial” way. I’ll have that app updated for newest release pretty soon. Maybe I can add kind of a quick start walkthrough to there.
Should I split the new discussion above into a new thread? This one has a pretty rough title.
3 Likes
In the case of MySQL would it make sense to use something GraphQL based?
I’ve been playing with tcomb-form since there is no great Simple Schema -> React based autoform (there’s a Material-UI one - but that’s a lot of overhead, and I don’t use Material-UI elsewhere).
I wonder if a SimpleSchema schema could be converted to tcomb’s schema format to use it that way? Maybe there is too much feature parity concern to make that worth it?
I think broadly, it’s interesting that the very integrated and opinionated Meteor/MiniMongo/Collection2/SimpleSchema/AutoForm/Blaze/Bootstrap stack is so easy to use it still has a lot of appeal for getting up and running fast (like - wow fast).
At the same time, React and GraphQL/Apollo are focusing in on abstracting out the various layers of applications into their own problem domains. With Apollo we are meant to think about the problem of Database structure and scale separately from our data API. With something like tcomb-form we are meant to think about how our forms go together and are validated separately from the rest of the stack. There are some optional tools that can take the form schema into your data tier, but it’s just interesting that each of these are sort of broken into isolation - it’s just so much different than Meteor’s initial vision.
I guess the question I have is, is that better? Did we learn (or should we have learned) something from tight integration? There have been times working with MongoDB that I wish I could have used a standard relational database. In general I like the idea of being able to swap out the various tiers in my app to better tailor the tech to my app’s specific needs. The problem of course is the extra work that entails - now I can’t just throw my database schema at a forms system, and magically get a self-validation form! On the other hand, I can make my forms look and interact precisely how I like (with much more work upfront).
1 Like
@captainn you might want to take a look at https://github.com/vazco/uniforms. It is a great and well-maintained package for form management in React. It provides elegant hooks to extend the functionality.
2 Likes
That’s great! I hadn’t seen that one before - thanks for sharing!
@radekmie also does a great job in maintaining it. Kudos to his hard work, uniforms is great
Edit. it has also a graphQL bridge - never tried it, but looks like a great idea to build forms based on graphQL schemas
Agreed, we use Vazco Uniforms with React and think it is great. We switched over last year from using Autoform with Blaze.
Autoform is a great piece of work and it… well, works. Even if there weren’t updates to it, it’s still useful for plenty of new projects, especially the ones written with pure Blaze.
So if somebody is wondering - use it or not - by all means try it.
On the other hand, I wish Autoform was frontend agnostic.
@sashko that would be a great thing to split it imho.
I used to do things like create a drop down in a simpleschema for autoform in the schema. I see there is a similar way to do that for uniform - but what I’d really like to do is override the field that is output in an AutoForm for specific fields (in the place that I need the form, instead of in the schema). Is that possible?
For example, something like a field on the AutoForm that takes an keyed object, and in the key a component can be set which would render a drop down or something like that.
1 Like
There are plenty ways to do it: create custom AutoField, specify the component in the schema definition (uniforms field in SimpleSchema) or use AutoForm with your layout (children prop) - then use AutoFields and/or AutoField and/or custom component. For more similar questions, I really encourage you to join uniforms Gitter room - you’ll get the answer faster.
Autoform is great and has saved us loads of time that’s for sure but it also has a few annoying bugs, mainly when working with arrays. Bugs like this one. It would be absolutely brilliant if you’re going to get some time to update it @aldeed.
Actually, I see @macrozone here who has been active in some of the bugs affecting us. Does Vazco Uniforms handle arrays well Marco? We’re still considering a move to React and Uniforms does seem to be the only option that works with Simple Schema.
i had no problems so far. @radekmie is also fast in answering issues on github, if you experience a problem.
it has also a nice playground to try it out: https://uniforms.tools
1 Like
Awesome, I’ll check out Gitter. I did notice the uniforms field in SImpleSchema, but there are two problems with that - one is just philosophical - I don’t really want my UI configuration mixed in with my Schema definitions (even though I would do it - I had done it that way with aldeed:autoform) - but the second issues is with code splitting. I’m splitting such that React doesn’t load until the UI is requested after routing etc. My Schemas and collections are all delivered in the initial package though, and if I mix in uniforms in my Schemas, presumably it’ll start to bloat my initial payload again by pulling in React and all the rest. I could refactor so that the collections load later, but I’m already over-budget as it is. 
You can define it like uniforms: {/* props here */} and then create custom AutoField, which will decide, which component should be used.
I think there’s always going to be people who want to build simple apps quickly. I just did an RSVP system for an event using autoform and tabular and it worked like a charm. I don’t know how well autoform (and meteor) scales to a giant giant app, but many people just need to build simple, small local or internal solutions. I think simple frameworks CAN be best for even huge apps, Rails proved that. That said though, massive apps shouldn’t be the only ones people think about, not all apps need to scale to a million users.
1 Like
Uniforms is turning out to be ideal for use in React apps - thanks so much for recommending it!
Here’s a rough of what I’ve done to create custom controls, and get them in my form - fairly easy to do once understood (though it was a bit tricky to figure out from the docs):
export default function TileForm (props) {
return <AutoForm
schema={ConfiguredPanelSchema}
onSubmit={doc => props.onSubmit(doc)}
model={props.tileData.toJS()}
autosave
>
<LinkFieldContainer />
<SelectField name="panel.kind" />
<TextField name="panel.label" />
<TextField name="panel.imageUrl" />
<ColorField />
</AutoForm>
}
Here’s the ColorField I made:
class ColorField extends React.Component {
handleChange = (color, event) => {
const {onChange} = this.context.uniforms
onChange('panel.color', color.hex)
}
render () {
const {model} = this.context.uniforms
return <div className="field form-group">
<label className="control-label">Link to</label>
<SketchPicker
color={model.panel.color}
onChangeComplete={this.handleChange} />
</div>
}
}
ColorField.contextTypes = BaseField.contextTypes
Basically, even though I got this working, and I guess my ColorField is a custom AutoField. I needed to first know what an AutoField was, and how it was connected to the model (and that there is a model, etc.) before I understood what "create an AutoField meant. I’m not sure I’ve worked it out correctly, but my solution works. Basically, I made a custom ColorField and LinkField (and LinkFieldContainer which pulls a list of objects from 2 Meteor collections) and update the properties from those components. There may be a better way (there is some kind of data connector, but I’m not sure why I need that), but this works.
UPDATE: Actually, writing this up prompted me to consider whether those hidden fields are doing anything at all - I think they are not - as removing them effects nothing! (ah, 2am work 
)
UPDATE 2: I removed the hidden fields from the example, since they are not needed.