I’m with vjau. I haven’t found any discernable advantages to react/state vs blaze components and reactiveVar/Sessions.
To me it seems the only difference is you have one file per component instead of two. The other thing being that having react on your resume is more appealing than blaze.
I was thinking today (as I struggle learning the massive lexicon of angular 1) that a user couldn’t tell the difference if you made this form with jQuery, Angular, React or whatever else. There is literally zero difference to them. The only real value of using any of these is (1) you can ship faster or (2) you can “maintain” it faster. Personally, I think react or angular are only marginally better than the old school way.
That said, angular is a nightmare. It’s just so sprawling it takes forever to get a grip on everything available. Sometimes it feels like it decouples things for the sake of decoupling. There’s like 15 js files between your ng-click firing on that button and it hitting the REST API.
There should be some cost-benefit methodology for measuring the value of “the next hottest thing” so you don’t spend 3 months learning something so you can use it for a month, save yourself 12 minutes of development time, and then have to learn the next hottest thing so you can save yourself 13 minutes a month.
Every once in a while I try to find the React way of doing something that is so easy with Blaze, and realize it will take me back a couple of weeks just to code the new way in our app, with no real benefit.
Not to mention the lack of maturity / consistency of many tools in React/Meteor. I have yet to see wide adoption by new devs to this ‘new way’. We may look back and say “this is what sunk Meteor”. Can’t wait until the community takes it over.
Autoform was a stepping-stone technology which grew organically to fit a need, but was never architecturally sound. It tries to template a templating engine, resulting in unnecessary levels of abstraction. And a very rudimentary theming technology got introduced when it probably shouldn’t have. The end result is that it became very popular because it was the only solution available, but the codebase is very difficult to work with. People eventually refactored it and cleaned it up, but the resulting refactors looked very different… like ViewModel, Nova Forms, etc.
I don’t want to speak for aldeed, but from what I understand he’s moved on from supporting Autoforms.
ps: Great work on Nova Forms, @sacha. Having poured through the Autoforms codebase for months trying to clean it up and get a handle on it, Nova Forms looks very much like the refactor we were always wanting. 5/5 stars.
pps. Although for people new to Meteor and Autoforms history, it’s probably important to note that NovaForms only supports Bootstrap input elements. If one wanted to have Material or SemanticUI input elements, one would have to decide whether to add if/then logic to the NovaForms or fork the library into Nova-Bootstrap, Nova-Material, Nova-Semantic, etc. Autoforms took the route of using if/then logic. And given that experience, it seems the better approach would be to fork instead.
Is it difficult to support something like accounts does? you add accounts-core (or ui? I forget) then you can just add additional syting with accounts-material, accounts-nostyles, accounts-bootstrap
Yeah, that’s actually a third option: use a plugin architecture. If about a third of Autoforms was ripped out and moved into separate packages, that would help a lot.
Thanks! I tried to keep the package as simple as possible, so apart for some weird logic for autofilling form fields (which I needed to autofill link titles/thumbnails/etc. when you type in a URL) it’s basically a big for loop over the schema that spits out the appropriate form control element for each field.
I decided to only worry about making it work inside Telescope Nova first, which is why I haven’t really pushed it as an Autoform alternative. But I did document and publish it, so if people would like to help me generalize it to any apps I think that’d be great. I’ve also been talking with @shilman about maybe refactoring it and moving it to NPM eventually, although it’s still a bit early to be able to do that.
Regarding the bootstrap/material/semantic/etc. thing, it’s true bootstrap is hard-coded right now. But it shouldn’t be too hard to switch it out (and if you don’t mind that you’re loading Bootstrap, you can even do this right now by just passing on your own React components).
It is still a bit surreal to me to find long conversations about my packages, especially when they have titles designed to bait me.
The tl;dr is: I’ve been busy but am planning to get back to it, split it up, port it, and involve more maintainers.
The current state of autoform and simple-schema as I see it: Stable, production-ready, and working well for 95% of cases. Some bugs around edge cases. This is my opinion based on my own usage. Your experience may vary.
I am pushing toward a SimpleSchema 2.0 release candidate, which will be an NPM package but I’ll continue to wrap that in a Meteor package for now to add some Meteor-specific icing. This package is more or less done and fixes all known bugs with SimpleSchema, but I’m still refactoring and rewriting tests. My goal is a much cleaner ES6 codebase that will encourage more contributions and more maintainers. If you think you are knowledgable enough to be a maintainer, let me know.
After that, I have sketched out a successor to Collection2, which should be pretty quick to write.
After that, back to autoform with a goal of porting it to NPM and either fixing or cutting scope to eliminate the edge case bugs. (Most “autoform bugs” are actually “simpleschema bugs”.) I personally am moving toward React, so I will either write a React version of autoform or help the maintainers of one of the react form packages that have already been created. Depends on whether we see eye to eye on some of the particulars.
Anyway, I’m happy to add maintainers. Let me know if you are a good candidate. And anyone can help by investigating and responding to GitHub issues for me. I promise I will look at and merge PRs eventually.
Thanks Aldeed for your great work so far (and what will come). Your packages have showed us the power of isomorphic code and enabled us not only to do fast prototypes (build admin uis only with schemas), but also showed new ways how to use forms (use autoform for cms-functionalities). Heck, you can even use simple-schema to genererate simple-schemas to generate a form, e.g. for a form-editor.
Having a npm-version of simple-schema will make testing much easier. It would also make it easier to use simple-schema in non-meteor-environments. E.g. kadira’s storybook (https://github.com/kadirahq/react-storybook) is a great way to create your UI-Components.
I just tried out this react-based autoform-variant: https://github.com/vazco/uniforms
It looks quite clean and simple and I could easily create my own set of Form-Elements with storybook. Having simple-schema in npm would also allow to show a full form in the storybook with just providing the schema (which could be for things like login-forms or register-forms where simple-schema-validation is really helpful).
So thanks again for your great work so far. I hope I can help with Issues and PRs! <3
