Why are you not trying to do the changes that you need yourself? If you think that you are not capable of doing that, you can pay a developer to do it for you.
2 Likes
Contributing to Autoform is not that easy, it’s a pretty complex codebase. Personally I built my own React-based alternative, but I also hear good things about Redux Forms.
3 Likes
@mitar,
autoform is indeed a really cool feature for Blaze. Thoughts on community taking over?
@thebarty,
Can you list the open issues that are important for you? Sizing up the work.
I use the AutoForm too.
+1
Yeah thats so true! On some issues I gave up after a few hours… its quite a beast.
@ramez14h:
Those are the “waiting-for autoform-bugs/features” in my project:
The is the long-term answer to things like autoform dying:
Unfortunately, it won’t help all the people depending on autoform at the moment…
#AnotherVictimOfOpenSourceDogma
1 Like
One thing you may want to consider is building your own forms library. It is surprisingly easy to do and you have the freedom to do whatever interesting and cool things you want! We are moving away from Blaze (and Autoform) at work and I’ve written my own forms library for React that works with Simple Schema. It’s been a lot of fun to work on. Form libraries are one of those things that you can always reuse and continually improve upon as you use it on different projects. Definitely worth the day or two it takes to throw an initial version together.
You’re welcome to take a look at what I’ve been building to get an idea of how simple it is to write your own library https://github.com/ryanswapp/blue-form It currently is geared towards Semantic UI but can easily be used with other libraries. Right now I’ve got some uncommitted changes that let you build out an entire form with just a schema. It lets you do conditional fields and all kinds of fun stuff so that all you have to do is drop in a component and specify a schema to get a nice form (similar to Autoform quickform but much more powerful). Hopefully I’ll have those changes published soon.
Anyways, just my 2 cents.
3 Likes
Making Blaze Components was inspired by ideas to make autoform-like forms really easy to do. I was really saddened to see how hacky you have to make things to make Blaze work in a reusable way. Maybe it is time for forms on top of Blaze Components. 
6 Likes
Delighted to see you still support the Blaze eco-system. Keep up the great work.
2 Likes
Hi,
One thing you may want to consider is building your own forms library.
sorry to jump in like this, but I have received a similar answer like this on anothor question. I really “don’t get” this. If something is easy to do, fine. But if it takes me only 1 hour to do, but someone has already done it, I would rather spend that hour on something else. 
To me, the whole idea of open source is that the collective makes things better. When a developer drops a project, someone else can take over - fine. But to recreate it, just for fun is nice, but might not be the most productive approach
regards,
Paul
2 Likes
This is the issue with free open source. Instead of having one solid library with solid support, we have to jump from distro to distro every other month. Build our own. It’s all very inefficient.
2 Likes
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.
1 Like
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.
2 Likes
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 use the AutoForm too.
+1
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.
4 Likes
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.
4 Likes