Had this issue open since last year. I recently updated it with new comments.
Actually, Eric worked on the CRF application prior to me, so UCSC has been supporting autoforms for a year or two now, in one way or another. I donāt know this for a fact, but it seems that Ericās declaring autoforms complete happened about the same time he left the CRF project for other opportunities.
So, like I saidā¦ weāve been writing acceptance tests in preparation for an underlying implementation change; and are keeping a close eye on Sideburns/ReactBlaze/etc. The exact implementation doesnāt matter too much to us, just so long as it conforms to the Spacebars APIs that was basically specified at Meteor 1.0. Once we make that migration, I suspect weāll look at mapping the autoforms functions to the underlying React functions, and removing the templating interface.
As for radios/checkboxes/selects, weāve gotten most all of that under QA with our Nightwatch scripts using css selectors. I used to be kind of uncomfortable with them, but am becoming much more confident with the QA tests. Whatās giving us headaches now are nested objects.
1 Like
@aadams Iāve posted a reply on the issue tracker 
Letās see if we can solve that problem there.
1 Like
It is very reassuring to know that there are so many tests running against autoform! Do you consider PRāing them to the official autoform repo?
Nested objects have their quirks, especially with their validation, but as long as they are not arrays, they can be tamed. I canāt say the same or arrays, especially with [Object] which contain boolean-radio's. Iāve had so many bug reports from clients reporting that they lose their state as soon as new lines are added to the array. And it is not a consistent bug so a reproduction is really hard to produce for an official bug report aaah 
3 Likes
More likely, weāre going to create a package that has a dozen form schema definitions, and a dozen acceptance test commands (which each get their own file, as per Nightwatch design). The new testing MVD includes a meteor test command which exposes test assets after build, which means that Nightwatch will be able to scan and pick them up.
Put another way, instead of internal unit tests, we want to create a package of a dozen forms that export testing helper functions that say āthis form should look like this, and have these elements after its renderedā.
Unfortunately, weāre dealing with Arrays alsoā¦ :sigh:
instead of internal unit tests, we want to create a package of a dozen forms that export testing helper functions that say āthis form should look like this, and have these elements after its renderedā.
Even better! Unit tests would probably not work for every app anyway, so a battle-tested examples of form definitions and accompanying test would be pretty helpful.
Unfortunately, weāre dealing with Arrays alsoā¦ :sigh:
Best of luck!
Since I moved to React land, I too wanted some sort of smart form that would handle validation, errors, etc., so I made one. 
https://atmospherejs.com/ffxsam/react-smartform
Itās still very preliminary, and I have a lot of plans for it. I still have to add textarea, select, etc., as well as adding callbacks to input fields for all kinds of custom functionality (verifying data in the db). Still, itās good enough to the point where Iām using it and adding stuff on when I have the time.
I probably wonāt make it generate fully complete HTML forms like autoform does. I want to keep it in pieces to give more control to the developer.
2 Likes
@serkandurusoy: OHHHHH NOā¦ why are all you good people leaving Blaze? 
I mean: Why switch to react when all we want is to program a business app. Is ReactNative really such an important selling point over the great Blaze? In other words: doesnāt Blaze and the aldeed:stuff combined with a responsive css framwork (making it mobile-compatible) do a great job - even on mobile?
@ffxsam thanks for sharing that. The thing is, this is kind of my point. React is not built for meteor, therefore as soon as I bring in react, I kind of lose a lot of the goodness that meteor offers. Starting with code duplication. Besides, what good is react if I canāt actually use the react ecosystem seamlessly? In other words, why should I then use Meteor if I go React?
Anyway, Iām still searching for the right toolsets and really donāt want to dive in blindly, just hoping for the better.
@thebarty thank you for the compliment, I guess and well, Iām not going anywhere, yet! @tmeasday shared an interesting opinion over at this thread.
My problem is, I need the stability since these line of business apps are developed for businesses who see their software investments as long term assets and donāt want to switch technologies unless there is some really serious business value. Therefore I need the peace of mind that what I deliver now will continue to get support, bugfixes and some enhancements, all the while allowing me to do general meteor update on the code.
Therefore, if react is whatās going to get me that, I have to go that route. But if blaze is to satisfy those conditions, then Iām undoubtedly all for blaze!
And finally, if Iām going to go with React, I need to pick the brains of the more experienced react developers to make sure Iām betting on the best possible component libraries that fit my requirements.
2 Likes
Iām not quite sure what you mean. React is just a layer over Meteor, in a similar way that Blaze is. Iāll grant you that Blaze is much more tightly adapted to Meteorās infrastructure with regards to reactivity, but Iām curious about what kinds of āgoodnessā you feel youāre missing with Meteor+React.
The big difference is that React Native is generating truly native code, whereas Meteor is using Cordova which is essentially a wrapper.
1 Like
what kinds of āgoodnessā you feel youāre missing with Meteor+React.
Blaze is obviously built from ground up to be part of meteorās reactive lifecycle. React offers it - officially - with a mixin, still lacking the ability to sprinkle reactive sources around. No automatic starting and cleaning of computations.
I know you and a few other brilliant developers are working to solve that problem, but I cannot rely on that.
Enterprises need the peace of mind of having official integrations. As far as official goes, react still feels like a square in a round hole.
2 Likes
No, I totally get that. It does still feel like React is kind of shoe-horned into Meteor with glue and tape. Iām sure (I hope) MDG is working on that, though.
2 Likes
Yep, I have no doubt when they finish up, theyāll have delivered a great integration. But when they do, when they doā¦
1 Like
To some extent, yeah. Your reactive business logic is limited to getMeteorData, but of course render will re-render based on changes to the data returned by getMeteorData. And there are some glaring bugs as well.
For me, Meteor+React didnāt really stick until I started using @luisherranzās MeteorFlux packages (meteorflux:dispatcher, meteorflux:reactive-state (Flux pattern), meteorflux:appstate (Redux pattern)). Now everything can communicate and function the way I want it to, without having to do insane things like pass callbacks four levels deep as props.
Oh yes, and then there are the mixed opinions revolving around whether or not meteor requires or indeed should not get flux patterns.
It is really very tiring and frustrating to have to do research, evaluate things and form opinions everyday, instead of getting things done. On top of that, finally feeling one day like the master of meteor universe and the next like a complete newbie just does not help 
4 Likes
Oh I feel like an idiot with this stuff on a daily basis. Donāt sweat it. Weāre all constantly learning, which is difficult considering how quick tech changes these days!
1 Like
Yep, I wish it did not change for a change
Itās been a couple of months since this conversation and Iām wondering how people have been finding React for line of business apps? This sort of work with lots of forms and tables is very much our bread-and-butter stuff and weāre really torn on whether to start our Meteor adventure with React or stick with Blaze for now and see what happens after 1.3.
@awatson1978 you mentioned a project migration to React, has that started and has it gone well?
@serkandurusoy did you find a solution that gave you some or all of the features from Autoform in React?
In the end, Iāve decided that blaze is āeasierā for a line of business
app where the main two ācomponentsā are ātablesā and āformsā and there
are lots of those, and not much of anything else. Tabular and autoform
make it almost too easy. Oh and I also find that a good pattern for
adding/editing/viewing is to do it within a modal and not leave the
"list" page for those actions.
3 Likes