Hi Adam.

my Name is Thomas. I'm a freelance and Indie Flutter developer from Germany. Maybe you have heard about me package get_it

I'm working on a package called interaction_manage that will allow you to show dialogs from non-UI parts of your code which is sometimes necessary. For this I planned besides some standard dialogs one that allows you to define your own forms in it. I actually started writing a packet with the same name quick_forms.

Before I continued after a longer break I decided to check pub if there might already be a package that solves the same problem, no reason to reinvent the wheel.

Your package looks really good and I would like to use it as a foundation in my interaction_manager package.

As it doesn't support all the things I would like to have yet, I would like to contribute to the package if that is ok for you.

Some initial thoughts/ideas maybe we could have a zoom call to discuss these before I start doing any PRs I write them down like they come to my mind:

• Naming; I know that's not the easiest part, but I would rename some of your main class FormHelper to QuickForm and pass that to the FormBuilder instead of piping the value through the builder. Helper is too generic and its the core class in your library.

• I'm not sure if it would be better not to generate the submit button out of the helper or if it would be better to let user wire their own button to a handler function inside the Helper because then you could define these buttons completely independent from the form but we could still provide standard builders that provide these buttons. following this I would also remove the submitButtonText from the Helper because this should be application specific.

• offering a separate ``String getLabel()to thegetWidget`

• Clear function to clear all entries

• Different options for placing the label (left/right/top/FieldDekoration)

• more control over validation like validation on field leave not on every key press

*TextStyle for fields and Labels

• Support for hint texts

• More Field Types like Checkbox, Date/Time, ComboBoxes, potentially creating sub classes from Field

• Function to create form definitions from JSON

• More form Builders

I really think this package has a lot of potential.

I would be happy to hear from you

Cheers Thomas

After spending more time with the code I'm tempted to change your approach of the Field definitions from a enum based to a class hierarchy one where every Field definition knows how to build its widget. This would make the package more flexible and users could easily add there own Field types. What do you think?

If you want to stick with your approach, I will probably split off my fork to a separate package.

I'm not sure if it would be better not to generate the submit button out of the helper or if it would be better to let user wire their own button to a handler function inside the Helper because then you could define these buttons completely independent from the form but we could still provide standard builders that provide these buttons. following this I would also remove the submitButtonText from the Helper because this should be application specific.