-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Form bloc no longer required and many other changes #308
base: master
Are you sure you want to change the base?
Conversation
feat a field no longer needs to be inside a form bloc to be visible feat now you can animate the appearance of a field even if it is only within a list fix removed the name field from the block fields. Now the organization of the form values is similar to a json fix now form bloc only manages the steps and not lists of field blocs fix removed the form bloc field in the bloc fields to have no dependency on the form and to be able to use any field at will feat Added validate method to form bloc. Validate the form without having to submit feat now the package no longer depends on flutter_bloc, use whatever package you want: get_it, riverpod, getx or singletons ;) feat added builders for lists and groups feat now the relatives have the status of the children. Fantastic isn't it? Remember to avoid unnecessary widget rebuilds
@SimoneBressan What is the benefit when the package not depend on flutter_bloc? |
@aaassseee You can use the flutter_form_bloc with get_it, riverpod or other, without having useless or unused dependencies or having name space conflicts |
@BreX900 I am not sure what useless dependencies and name space conflicts that you are talking about. Reading with the pull request, I think you only replace bloc provider and bloc listener with your self made classes which is still depending on bloc. To be honest, library user who are using get_it, riverpod or getx would not consider this library as their solution due to the library name form_bloc. Making the library not depends on flutter_bloc but still bloc will not increase the user acquisition. In addition, by the past experience. Cloning library and make it on you own with few changes is a bad idea. Because all the users expect the library behavior is same as the library that you cloned. For example, people who use bloc will expect the same result with your self made bloc listener. Moreover, self made library is hard to maintain because not many contributor migrate the latest function or bug fix on cloned library . This will make contributor much more harder to do migration or maintenance for the time being. Like flutter_typehead it is hard to maintain nowadays, because lots of changes were made. If we use another library as our dependency we should depends on it instead of making our own. I think this direction should be the right play. |
Hi, @BreX900. Any update on this pull request. I am willing to help. |
@aaassseee You are right regarding removing flutter_bloc. It is best to keep it. |
@BreX900 @SimoneBressan Thanks, check discord please :) |
I would recommend creating a dev branch and releasing this version in dev. It's not over but feedback is always welcome
Changes: