You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am having a use case which is actually not so complex, but I am doubting on how to properly implement it using Bloc (and the formz package). I already opened an issue in the formz package (VeryGoodOpenSource/formz#110), but I think this might be even more related to Bloc itself. I set up a simplified example repository, which can be found here: https://github.com/WieFel/person_form_bloc
Let's assume the following:
We want an app that enables us to create a list of people (Persons) which have a name, age and role (child, adult, senior).
First of all we create a person form to handle the logic of inputting the data of one person.
The fields have some dependencies between each other: e.g. the role child can only be chosen if age < 18 etc. For implementing that validation logic, we wrap the form inside a PersonFormCubit. In its state (PersonFormState), it holds the 3 fields (FormzInputs using the formz package, but this actually doesn't matter) and an isValid flag which indicates whether the form is valid.
Until here, everything works fine. But now we want to take it one step further:
Event attendee list
We want to have a form in which we can dynamically add Person entries, e.g. an attendee list for an event we are hosting.
We have a button for adding new attendees to the event. The state is held as a list of PersonFormState in the EventAttendeeState (see here).
The EventAttendeeBloc reacts to the adding/editing/deleting of persons in the list.
The list is implemented here as follows (simplified):
BlocBuilder<EventAttendeeBloc, EventAttendeeState>(
builder: (context, state) {
returnColumn(
children: [
Expanded(
child:ListView.builder(
itemCount: state.attendees.length,
itemBuilder: (context, index) =>BlocProvider<PersonFormCubit>(
// here we create the wrapping cubit for each person list entry
create: (context) =>PersonFormCubit(state.attendees[index]),
child:PersonForm(
onChanged: (newAttendee) {
context
.read<EventAttendeeBloc>()
.add(EventAttendeeChanged(index, newAttendee));
},
onDelete: () {
context.read<EventAttendeeBloc>().add(EventAttendeeDeleted(index));
},
),
),
),
),
ElevatedButton(
onPressed: state.isValid ? () =>print('SAVED!') :null,
child:constText('Save'),
),
],
);
},
)
Questions
First of all, we are not completely sure whether it is fine to hold a List<PersonFormState> attendees in the EventAttendeeState, or what could be possible alternatives to that approach!?
We have the problem that removing persons from the list doesn't work properly with this implementation.
E.g. if we have added 3 persons to the list (Person 1, Person 2, Person 3) and remove the "middle" Person 2, the internal state is updated properly, but the UI is displaying the wrong state (it wrongly displays Persons 1 and 2, instead of 1 and 3). This is probably because the BlocProvider<PersonFormCubit>s create function is not executed again. Trying to force a re-creation of the subtree by adding a key to the BlocProvider<PersonFormCubit> only brings other side effects, e.g. that the form fields lose focus on every character input, because the form is re-created on every character input. What would be the suggested way to handle such a case of nesting a dynamic list of cubits, inside another bloc?
The text was updated successfully, but these errors were encountered:
Closing for now since there aren't any actionable next steps. If this is still an issue feel free to respond to @tenhobi and we're happy to continue the conversation 👍
Hi,
I am having a use case which is actually not so complex, but I am doubting on how to properly implement it using Bloc (and the formz package). I already opened an issue in the
formz
package (VeryGoodOpenSource/formz#110), but I think this might be even more related to Bloc itself. I set up a simplified example repository, which can be found here: https://github.com/WieFel/person_form_blocLet's assume the following:
We want an app that enables us to create a list of people (
Person
s) which have aname
,age
androle
(child, adult, senior).Person form (can be found here)
First of all we create a person form to handle the logic of inputting the data of one person.
The fields have some dependencies between each other: e.g. the role child can only be chosen if
age < 18
etc. For implementing that validation logic, we wrap the form inside aPersonFormCubit
. In its state (PersonFormState
), it holds the 3 fields (FormzInput
s using theformz
package, but this actually doesn't matter) and anisValid
flag which indicates whether the form is valid.Until here, everything works fine. But now we want to take it one step further:
Event attendee list
We want to have a form in which we can dynamically add
Person
entries, e.g. an attendee list for an event we are hosting.We have a button for adding new attendees to the event. The state is held as a list of
PersonFormState
in theEventAttendeeState
(see here).The
EventAttendeeBloc
reacts to the adding/editing/deleting of persons in the list.The list is implemented here as follows (simplified):
Questions
List<PersonFormState> attendees
in theEventAttendeeState
, or what could be possible alternatives to that approach!?E.g. if we have added 3 persons to the list (Person 1, Person 2, Person 3) and remove the "middle" Person 2, the internal state is updated properly, but the UI is displaying the wrong state (it wrongly displays Persons 1 and 2, instead of 1 and 3). This is probably because the
BlocProvider<PersonFormCubit>
screate
function is not executed again. Trying to force a re-creation of the subtree by adding akey
to theBlocProvider<PersonFormCubit>
only brings other side effects, e.g. that the form fields lose focus on every character input, because the form is re-created on every character input. What would be the suggested way to handle such a case of nesting a dynamic list of cubits, inside another bloc?The text was updated successfully, but these errors were encountered: