I don’t see how React has anything to do with Astronomy in this context. The best way to use Astronomy is to interact with your data through Astronomy, always. You ensure your data is never dirty and always follows the spec you lay out.
If you have a server/models/product.js or server/models/category.js, you can use whatever you want on the frontend, just make sure you are speaking through Astronomy.
Which still requires a standard schema interface, no? If you have a validator function, you can do validation, but you still can’t do form generation, that requires an actual data structure.
Yes you’re right. However, let’s consider this question. What do forms package need to display form fields? The first important thing is field name and type to display proper form field. I would say it’s basic and sometimes only requirement. Of course, you could also pass max or min length or information if it’s an email or something like that. So both SS and Astronomy could generate such simple schema for forms package.
I would see it in the following way.
var Form = new Form({
schema: function() {
// Astronomy
return User.getFromSchema();
// SimpleSchema
return ssUser.getFormSchema();
// Both returning something like:
/*
{
firstName: String,
email: String,
address: {
city: String,
state: String
},
phones: [{
name: String,
prefix: Number
number: Number
}]
}
*/
},
// Astronomy
details: {
email: {
type: 'email',
minLength: 2,
maxLength: 10
}
},
// SimpleSchema
// From what I know SimpleSchema could generate it automaticaly maybe
// Astronomy could also do it automaticaly - I don't know right now.
details: ssUser.getFormDetails(),
validate: function(values) {
// Astronomy
var doc = new User(values);
try {
doc.validate();
}
catch (err) {
return err.details;
}
// SimpleSchema
var context = ssUser.getContext();
try {
context.validate(values);
}
catch (err) {
return err.details;
}
}
});
Yeah that makes sense to me - you’re saying that you need a lot less information to generate a form, and Astronomy and SimpleSchema should be free to add any features on top of that. Makes sense to me, thanks for explaining!
Astronomy does not change anything if it goes about usage of React. Blaze is not its dependency so you can use it with any template framework. In fact there is an example of Astronomy usage with React.
Things will change with the introduction of GraphQL, however after watching Transmission - Episode 2.1: Reactive GraphQL I know that it won’t happen soon, which is good. I’m gonna have time to prepare for it. Right now schema definition is prepared to work with GraphQL, however I can’t do more as I don’t know details of Meteor integration with GraphQL. As far as I know DDP is still a standard way of exchanging data between client and server. When GraphQL support will be available I will probably have to create special module that will use GraphQL instead of DDP, but that shouldn’t be a big problem.
So I’m happy to announce that I’m ready for a change, just waiting for information 
Here’s one example: https://github.com/danieltapia/mercadera
We’re using Meteor, React and Astronomy. Works perfect, no ceremony. 
Thanks for the heads up and clarification. I thought deeply about which model management package to adopt. It took me months. I’m new it took a minute for Astronomy to catch my attention. Long story short. I’m really excited about Astronomy. All the talk about minimogo, states, stores, etc. left me confused about where Astronomy fits. A good illustration would help
The code is, for lack of a better term, adorable! I also Like the way you leveraged Astronomy. Nice. Thanks for the clarification.
Thanks! That’s what we’re aiming for with this open source project. No ceremony, simple code to show how powerful Meteor is.
Food for thought: http://zedshaw.com/archive/the-master-the-expert-the-programmer/
I used to be this way. I used to love complicated designs and read everything I could about complicated technologies. But as I get more experienced and “older” as a programmer I find complex things just annoying. They aren’t a mental challenge to understand anymore, they are just irritating. I’ll pick apart the flashy crap, boil down the technology to its essence and then come up with a much simpler design for the task at hand almost every time.
What worries me though is how the experts react to my simplified designs. Typically they’ll say that what I’ve written is not “following best practices” or “isn’t well designed.” They’ll propose these endlessly complex designs with endlessly imagined failure scenarios, and not realize that what they are doing will be a nightmare to maintain. The experts will then saunter off to implement their Flaming Tower of Babel without any comments, horribly complex mock enabled tests, making sure EVERY SINGLE CLASS HAS AN INTERFACE, and ending every class with “Impl” because, well, that’s the best practice. After implementing it they’ll continue to complicate the design even further with endless seemingly aimless refactorings for no other reason than to refactor. And when they’re done, I’ll go in and read through their code and cry.
I think it’d be very useful to get @aldeed’s feedback on what he’d do differently if he were starting Autoform from scratch today using React. I know he has some ideas on how Autoform could’ve been more modular, for example.
This approach is a lot more modular.
The core package doesn’t has a lot of lines and its very easy to create custom components.
I would love to hear @aldeed’s feedback.
Why are people saying there’s no forms solution for React?
There’s so many out there, and these are the ones that I found that are decent:
https://prometheusresearch.github.io/react-forms/
https://www.npmjs.com/package/react-joi-forms
http://jquense.github.io/react-formal/docs/#/?_k=6we37a
With the arrival of 1.3, shouldn’t our search scope for solutions be bigger?
Certainly a valid point: with the release of Meteor 1.3, we have the entire NPM repo to utilize should we choose, albeit none that will integrate with SimpleSchema or Astronomy, and isn’t that the main point of this discussion? (Or am I missing something?)
Yes I think that’s exactly the point, this is all about Meteor flavoured React which you don’t get in npm.
Okay no problem, I just wanted to point these out so people don’t feel limited to these solutions.
I’ve definitely been pondering this lately, but I’m trying to finish rewriting SimpleSchema before moving on to what to do about autoform.
I definitely think it’s a good idea to try to have separate packages for auto form generation vs. auto form state/validation/submission. The latter can easily be done as a vanilla js library, which might already exist, and then packages can wrap it to convert events into reactive UI updates.
I agree that the best approach is to use the best of what already exists as stable npm/jQuery packages and write small adapters if possible.
The devil is in the details. There are many places where the current tighter coupling is nice and will be hard to properly split.
If anyone wants to work on this or already has related packages or ideas, contact me and I can try to coordinate efforts.
This code looks very nice and clean @nicolaslopezj. I would not miss Autoform, and since I’m using React, autoform doesn’t work anyway.
I’m looking into how to use it for my project. For example https://github.com/mantrajs/meteor-mantra-kickstarter is using tcomb-form, but I think MRF is much nicer, especially for Meteor support.
I wonder if you’re planning to use MRF for Orionjs 2.0, or you’re sticking with Blaze, or both options, or is Orion even being developed further given Meteor is moving towards NPM?
Now I would to try Mantra too.
My old project use Auto Form at all, so I have problem about this.
All of sudden, there are plenty of Autoform-like packages for React.
One of the best so far for me is this: https://github.com/vazco/uniforms
The code is clean and straight-forward. You can easily create your own form-components and e.g. design them in a storybook (https://github.com/kadirahq/react-storybook).
I hope that one or two of these packages become a defacto standard like autoform. This would lead the way to schema-based admin tools like orion or meteor-admin, but in react. 
I just want to also plug uniforms - I’ve been using it for a year+ and it’s beautiful. It has magic AutoForm & AutoField, but you can use each component (forms and fields) without the magic and creating your own custom variations is pretty easy (very easy once you understand how it works).
You are not locked into redux, mobx, meteor, nor whatever, but you can easily integrate with any of them (a custom AutoForm.onChange or other form to tie state into whatever system you want) – it also works with a variety of schemas.