Welcome to the new @autoform library!

[vantezzen]

AutoForm is now a full library!

AutoForm quickly grew from a small component into a codebase larger than any shadcn component should be. To let AutoForm grow without bloating your shadcn/ui components, AutoForm is now a full library!

• Complete rewrite; AutoForm now has a core library that is agnostic to your schema library (zod etc.), renderer (React etc.) and UI library (shadcn etc.)
• @autoform/react now contains the basic logic to render the forms, independent of UI library and removed the dependency on react-hook-forms
• AutoForm now has support for shadcn, MUI and Mantine with plans to add more

Check out the new AutoForm documentation for more information.

The new AutoForm does not have full feature-parity with the old AutoForm as we look into what features actually make sense and which once just bloat the experience. If you're missing a feature or have problems with the new library, feel free to create a comment under this issue or create a separate issue in this repo.

Issue from the old shadcn implementation have been closed. If they are still relevant for @AutoForm, feel free to re-open yours!

[tecoad]

@vantezzen Just checked it out.
Should be nice to write some migration guide from older users of Autoform.
For example: how do i access formStates? isDirty, isSubmitting.. etc.?

I read the source, seems i can no longer access formState? Have i missed something?

[vantezzen]

Thank you for the feedback - I'll work on a migration guide!
As for formStates, AutoForm removed the dependency on the react-hook-form lib since that complicated implementing some features. Due to this, there is currently no information on isDirty, isSubmitting etc. stored in AutoForm - but that could be added in the future

[tecoad]

@vantezzen I admire you courage to totally spin off.
Even by removing some vital features such as form states.
I understand that this might be "a step back to make three forward" approach. But in this case, it's just a five step back, IMO.
Your focus seems shifted from growing in depth by enabling more usecases to grow in wideness by enabling more frameworks/schema validation/ui libraries. Not sure if its a senseable decision to compete with react-hook-forms at the end. From what i see on past-issues, new version won't cover most of usecases as just yet. Imo, trade-offs on the new version are just not worthy at all at the moment,
You are also basically turning down to shadcn users that like "copy files and make your own" way of doing.

Such a different product should have been done in a separate package, both being maintained until what your vision "autoform package" accomplishes as equivalent at the minimum on what it already is. It's just my opinion that you killed this repo, at least for shadcn users. I am honestly considering to fork it to keep it maintained.

[vantezzen]

I definitely understand the critique. As for the shadcn component, it's still available in the https://github.com/vantezzen/autoform/tree/pure-shadcn branch and I'm absolutely open to still accept PRs to it.

But generally I had the feeling that AutoForm morphed from a simple way to add low-effort forms for existing schemas into an overgrown form library that didn't want to admit it is one. AutoForm uses its own config syntax, separated from the declaration of the schema itself, that requires it's own learning curve - adding inline React components with poor typing etc.

Putting all the logic to parse and transform zod schemas into the shadcn UI component folder just complicated customizing the component for users who don't want to deep-dive into how it works under the hood. This also makes updates incredibly difficult as the new code is intertwined with the customized code by each project, so using new features requires manually merging those two - which the shadcn CLI just isn't made to do. That was the main goal of the rewrite - to separate that parsing (@autoform/core and @autoform/zod) and boilerplate for rendering (@autoform/react) from the project-specific parts like components.

Looking at the open-source repos using AutoForm (https://github.com/search?q=function+AutoForm%3CSchemaType+extends+ZodObjectOrWrapped%3E&type=code) I noticed that most only customize the fields, adding their own or customizing how labels etc. are rendered. The new version still allows that, and I want to continue developing the library in a way that it's open to expand with additional features - maybe even with some kind of plugin system that allows power users more control and features.
But adding all those features into the old shadcn component was nice for the power users but made getting started more difficult for user who actually just want a simple, automatic form and are instead met with a >700 line README.

I'm generally open to switch to react-hook-form in @autoform/react and other changes to the new library if it improves the DX of the library and allows better customization without overcomplicating things.

[tecoad]

@vantezzen I totally respect your opinion but i have a different vision on the features that made this repository gain traction among its current users. (You can't just evaluate the non-private repos). And its really simple:

We all agree that setting up a form is a pain in the ass. UI > hooks > client side validation > server actions, etc. Autoform enables this in one single file. It abstracts things while keeping most of the flexibility. Example:
What if you want to disable submit button while the form is not validated? (Is this really not common??? Check this github comment textarea for example.)
Users of this package do want to simplify and abstract things, however they don't want to get hid of (basic) flexibility! Which you just done. At the end, you made a (very) basic usecase just a no-usecase.

Putting all the logic to parse and transform zod schemas into the shadcn UI component folder just complicated customizing the component for users who don't want to deep-dive into how it works under the hood.

LOL! Complicated customizing? You had done a great work on mixing easiness and flexibiity.

But adding all those features into the old shadcn component was nice for the power users but made getting started more difficult for user who actually just want a simple

Couldn't disagree more.

Not need to think too much to notice the huge setback:

No formstate
No Custom parent components
No Custom order
No Dependencies between fields
No Declaring custom field components inline
X
Array
Yup
Cleaner, ...
Cleaner, ...

Now you will try to make this gain popularity among other framerwork/ui/schema users, but you lack the most of basic customization.
I highly believe that you made the wrong decision here just yet for your current users.

[artanisdesign]

I'm relying on depedencies between fields a lot.. so cant migrate yet..
just about to finish a large-ish project with the prev version of autoform... where obviously i had to customize stuff.. that wont make easy to migrate to the new version :/

[leomerida15]

@vantezzen I totally respect your opinion but i have a different vision on the features that made this repository gain traction among its current users. (You can't just evaluate the non-private repos). And its really simple:

We all agree that setting up a form is a pain in the ass. UI > hooks > client side validation > server actions, etc. Autoform enables this in one single file. It abstracts things while keeping most of the flexibility. Example: What if you want to disable submit button while the form is not validated? (Is this really not common??? Check this github comment textarea for example.) Users of this package do want to simplify and abstract things, however they don't want to get hid of (basic) flexibility! Which you just done. At the end, you made a (very) basic usecase just a no-usecase.

Putting all the logic to parse and transform zod schemas into the shadcn UI component folder just complicated customizing the component for users who don't want to deep-dive into how it works under the hood.

LOL! Complicated customizing? You had done a great work on mixing easiness and flexibiity.

But adding all those features into the old shadcn component was nice for the power users but made getting started more difficult for user who actually just want a simple

Couldn't disagree more.

Not need to think too much to notice the huge setback:

No formstate No Custom parent components No Custom order No Dependencies between fields No Declaring custom field components inline X Array Yup Cleaner, ... Cleaner, ...

Now you will try to make this gain popularity among other framerwork/ui/schema users, but you lack the most of basic customization. I highly believe that you made the wrong decision here just yet for your current users.

Hi @tecoad I think the same as you, in fact I went through an issue that raises something similar with the incorporation of another package to the library

issue: #124

npm: @form-instant/react-input-mapping

It only deals with the rendering of the inputs and is compatible with the form hook, the UI library and even the idea that in the future it will be the schema library, I hope you can take a look at it, I want a more comfortable solution to emerge and I feel that this repository is moving to be more restrictive and difficult to work with.

[tecoad]

you totally got it, @leomerida15
I agree 100% with your point of view.
It seems that there was a focus shift in the repo, turning it way more complicated than it should be, and my guess is that @vantezzen already realized it.

As a package maintainer his focus should always be to set clearly the focus for the product vision and goal, in which we could collaborate with. Once he kills what has already been achieved and is being used (as for @artanisdesign), you kill the repository.

[vantezzen]

As a package maintainer his focus should always be to set clearly the focus for the product vision and goal, in which we could collaborate with

I created the original shadcn AutoForm for a side project of mine. I now needed similar functionality for two freelancing projects with MUI, Mantine and yup. I didn't want to rewrite it for each so I decided I want to create a universal project that I can use in these and future projects.
That is my focus: For it to work for my projects, and the current version handles that perfectly.

I decided to open-source it since I know other developers are facing the same issue and if my version of an automatic form meets their needs I'm happy to share.
Same goes for contributions - I'm happy to merge PRs as it improves the experience for everybody and implement feedback myself if I think it could improve the usability.

As for complexity, I get that the new AutoForm is more of its own ecosystem instead of the freestyle approach of the old one. The main reason for this is that I want to provide more robust extension points with clear typing so it doesn't break when things are expanded.

Looking at the form-instant library linked here for comparison, though I see many of the same elements:

https://github.com/leomerida15/form-instant-react-resolver-zod/tree/main/src/funcs is literally of copy of https://github.com/vantezzen/autoform/tree/main/packages/zod/src

https://github.com/leomerida15/form-instant-react-mapping seems to lack many features AutoForm has as I think you need to manually provide sub-objects via elements, no array-support, no react-hook-form support etc. - of course adding those again increases complexity and needs that code either as part of the package or individual projects, again adding the complexity with new features.
I tried testing the library but ran into TypeScript and compilation errors and it seems like the "createZodSchemaFieldConfig" function the README references is not exported by the package (https://codesandbox.io/p/sandbox/form-instant-test-pm2v2d).

[leomerida15]

Hi @vantezzen, I came to this project for the same reason that this repo was created, to better manage forms in multiple projects.

About it being a copy I see that it is a refactoring I took the code from

https://github.com/vantezzen/autoform/tree/main/packages/zod/src

Since I did not plan to rewrite the wheel I will add a note about this in version 1.0.0, regarding codesanbox I see that they are errors of that project I have just used this library in sanbox with the same versions and I do not understand why it breaks in your project

I will attach a complete functional example
Example.

I'm glad you see the package. If you see another error, I'd like to know about it. I hope you take @tecoad's ideas and mine as help. The proof that I like this project is that I try to contribute to it, since the fieldConfig method is born from an issue that I commented on a while ago #105 and that also prompted the idea of ​​creating a provider #106. With that said, I hope you take it into account.