flutter-form-builder-ecosystem / flutter-form-builder-ecosystem/flutter_form_builder
[General]: Log warning when `patchValue` does not find a corresponding registered field
- Dominant language
- Dart
- Stars
- 1.6k
- Forks
- 561
- PR merge metrics
- No merged PRs in 30d
Description
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Package/Plugin version
9.3.0
### What you'd like to happen
In the `FormBuilderState.patchValue` method, the code takes in the new value map, iteratively search for a registered field with the map key, and calls the field's `didChange` method if the field is found.
Developers that are not familiar with the inner workings with the library may often wrongly assume the `patchValue` method updates the value of the form, regardless whether the FormField is present or not.
This is often the case in my team of developers when we are using this library. Since conditional rendering is a very common practice in the Flutter framework, one may do something like this:
```dart
setState(() {
new_field_should_render = true;
});
formState?.patchValue({
"new_field_name": new_value,
});
...
// under build
if (new_field_should_render)
FormBuilderField(
name: "new_field_name"
),
```
This will not work as the field has not yet been registered. The workaround is to either use `Offstage` to make the field always stays inside the widget tree, or to call `patchValue` a frame later using `addPostFrameCallback`
However, debugging this is not easy.
I suggest we can add a warning log when `patchValue` cannot find the respective field using the key inside the map, warning the developer that the field with the given key is not registered and therefore the update to that field is ignored.
### Alternatives you've considered
_No response_
### Aditional information
_No response_
Contributor guide
Research direction
Start by locating FormBuilderState.patchValue and read how it searches registered fields and calls didChange. Reproduce the conditional-rendering case from the issue, then verify that an unregistered key produces a warning while registered fields still update as before.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart
- Domain
- mobile-dev
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100