This assumes that insert-open-source-project works correctly and can fill all of your use cases. I think your right that many times it is a better choice to use a proven piece of open source software rather than build your own (e.g. using Blaze/React is often more productive than writing your own view layer). However, I’ve found that I often spend an absurd amount of time trying to bend some open source projects to my will (for even silly things like being able to put html in a form label with simple schema and autoform). Many times it is faster and more productive to build (or fork) a project yourself and develop a custom solution that you can reuse on all future projects. After building many a Meteor app it has made sense for me to build my own forms library and I really enjoy having total control over that aspect of my app.
I didn’t intend for my original answer to come across as a brash “just build your own” type answer. It’s just that my experience has shown that having a custom forms library has increased development speed and made my life easier. As a result, I suggested that the author consider it as an option now that Autoform appears to be lacking in support.
@pwiegers, the challenge is that the autoForm library is not dev-friendly in its coding. Look at the number of open issues, people couldn’t figure out how to resolve those issues in a reasonable time. However, I believe you are generally right that the approach of open source is to pick up and keep running as opposed to going back to the start line.
Couldn’t agree more. It’s a great way for React introduction as it is just pure React that you will be playing with, and in the future 100% relying on.
I also built one that we use at work https://github.com/MechJosh0/meteor-react-autoform. It’s going through changes at the moment to allow isolated testing and have it working with Storybook. The advantage is that we know it’ll have continuous work on it with anything that we ourselves need (fixes or features), and it’s built with all the cases that we need, as it’s a major part of the platform this is important.
One thing I am very worried about is Simple-Schema blocking testing. We’re unable to run tests around Redux Actions and React containers (knock on affect from importing Redux actions) which include Simple-Schema for client side validation. Aldeed does have a [WIP] repo on it but he hasn’t worked on it in 3 months.
My worry is can our project (in development) wait until Simple-Schema is in NPM to ensure we have more test coverage before we launch or should we build our own version.
Autoform is dying as well as Blaze, because of new technologies as Angular and React. These “new” front end work way better than Blaze, results are better, code quality is better, etc. That’s why you see all developers migrating. Resist to the change is a common but bad practise, you have to learn to adapt. Software changes constantly and we have to move with it, otherwise you will be working with outdated tools your whole life.
Now that people have moved from blaze, I can recommend you to use a equivalent tool for React. I’ve been working with simple-react-form which uses simple schema and works pretty scimilar to Autoform.
I’m currently in the process of rewriting my main app frow blaze to react.
In the end i don’t find my code to be better, and i’m clearly much less productive with react than with blaze.
In my case i’m not migrating because i believe React to be better, but only because MDG is not developing it anymore.
From now on il will try to use only techs that are widely adopted. Rewriting software that works is not fun.
One other way to say it would be that you will be working with stable and time proofed technologies, versus struggling with the unstable / always new / always changing techs.
When you are learning something new, probably you will start slow.[quote=“vjau, post:19, topic:24361”]
In the end i don’t find my code to be better, and i’m clearly much less productive with react than with blaze.
[/quote]
Probably bacause you are still learning? I started slow too… but In the end when your project gets bigger, it will be easier to mantain and you components will be reusable.
I find it pretty fun because you find ways to make it even better.
That’s one way to see change… the other way to see it is that you can contribute to make things better, you get to learn faster, you feel like you are in the bleeding edge of software development, etc. Lot’s of good stuff get’s better… but yeah… there’s that thing that you have to change several things in the way.
My father is software developer too, and he got stuck with Algol for years… now it’s really difficult for him to catch up new stuff because he is not used to learn new technologies, it’s difficult for him to find a new job, etc. Both things have pro an cons… This thing is moving and is up to you to move with it or get stuck in the middle.
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
