Closed BenjiFarquhar closed 4 months ago
hi
it will be better to create separate ...FormModelBuilder
for those cases.
widgets that are mixing 2 approaches in one - not the most flexible solution
This comes obvious if we check the code
this are two code smells that signify the need to split
if (widget.model != null && widget.formModel != null) {
throw ArgumentError('Cannot provide both model and formModel.');
}
if (widget.formModel != oldWidget.formModel) {
if (widget.formModel == null) {
throw ArgumentError('formModel must not be set to null');
}
_formModel = widget.formModel!;
}
@vasilich6107 That should be fine; I can look into doing that, but it probably won't be super soon. What are those code smells? Is it because the consumer of the package might use it incorrectly?
Edit: I'm pretty sure the second code block will be necessary even when split into another widget? Oh, or just make it required non-nullable...I see
@BenjiFarquhar First and most important - we use one widget for 2 purposes. We have to additionally check incoming operators. We have to act differently in did update widget and init state. In case if there are more changes required we will have to modify the widget more and more(in case if we have separate widgets we just need to fix only the necessary prart)
Probably I could help you with splitting. may be later this month
If you want to manage the form lifecycle manually, you can now pass
formModel
instead ofmodel
into theFormBuilder
widget. The behaviour remains the same when passing inmodel
.The required check for
model
:needed to be moved to
initState
, because it is now possible to pass informModel
, meaningmodel
would no longer be required even if_element.isNullable
is false.Also fixed the order of
super
calls.