So I learned meteor years ago and now am coming back to this crazy new world of react/etc.
I need to make some complicated forms. I sorta want to do it manually for the control… are they any good examples/tutorials online of how to do complicated forms (nested) using react and meteor. I really liked https://themeteorchef.com/tutorials/building-complex-forms
but it’s in blaze. - Any thing like that with react?
THANKS for any help.
Sam
Definitely checkout viewmodel/react - that will drastically reduce the amount of code you have to write, particularly with forms. Validation is a breeze, bits of the form can appear/hide automatically depending other properties, plus it removes all the react boilerplate. The result is code which, literally, makes you smile 
If you’re writing complex nested forms, the section on Sharing Properties is useful so you can have bits of the form in a child component sharing the same properties as the parent component(s).
Good luck!
Take a look at https://uniforms.tools/ which is implemented brilliantly. The documentation is awesome, author responsive and the community quite vibrant.
THANKS! - So I guess typically you use a form library in addition to react? (yikes I guess) Thanks for your help!
Well, not necessarily. But as in most software, it helps to build some abstractions around common patterns. Forms are historically hard to properly nail, therefore using a suitable forms library does get you a long way.
As I make the transition from Blaze and Autoform to React (it seems), I’m in the market for good patterns around form creation and validation.
I’m always weary now of getting “bitten”, like I was with Autoform. It was far and away the #1 forms lib for Meteor – abandoned by the creator, and then never resuscitated by the community (that includes me of course).
After that experience, I will always prefer “native” (no libs) form building if possible and practical.
have you found any tutorials that cover a complex form in react?
Autoform was a different beast (beast being the operative word). Most react form libraries, however, are a breeze to understand because they are so simple and explicit, due to react’s working mechanics. React makes composition very easy, and that makes extending and customizing these libraries very easy in return.
I do agree that existing libraries take varying degrees of abstraction. Where one tries to do a multitude of things, another does very little. I strongly recommend you evaluate a few of those, take a peek at their source code and perhaps you’ll even decide to start writing your own very little library and gradually shape it towards your requirements.
Remember, everything in react is a component! This is a shift in paradigm coming from Blaze and once you get the hang of it, you’ll take those libraries for what they are, components!
I’ve gotten bitten by Autoforms a few times, and have been very reluctant to hop onto any templating libraries for React. The problem with Autoform (imo) was that many people didn’t recognize that Blaze was already a templating/form library… just a low-level granular one. So it wound up adding a templating layer to a templating layer. And that way madness lies.
Also, a lot of people wanted to use Autoforms because they wanted to auto-construct forms from schemas. Which sounds great in theory. But 9 times out of 10, they want minor styling updates. And those minor styling updates build up, eventually approaching the amount of complexity that it would have taken to just implement in Blaze in the first place.
That being said, I’m really liking what I’m seeing with Uniforms. I think it might be the best iteration on the Autoform concept yet.
HOWEVER. At this point, I also think it’s only appropriate for use cases which require a form builder or a large number of auto-generated forms. Want to create an app for generating surveys and questionnaires on a weekly basis? It’s a good fit. Anything else, though… better to custom code the form.
Using the FHIR data models, we’ll probably wind up supporting Uniforms with the Questionnaire and QuestionnaireResponse resources. Maybe the Basic resource, or for some of the idiosyncratic resources that we haven’t gotten around to writing custom forms for. But the general idea will be to start with Uniforms; modify it as little as possible; and move off of it to custom forms as soon as possible.