#flutter #dart #bloc
Вопрос:
Недавно начал использовать блочный подход для создания приложений, и одна вещь, которая не ясна, — это где «хранить» блочные переменные. Я думаю, у нас могут быть эти два варианта:
- Объявите переменную в классе блока; например, в моем классе я могу сделать следующее:
class ModulesBloc extends Bloc<ModulesEvent, ModulesState> {
late String myString;
}
И получите доступ к нему в моем пользовательском интерфейсе следующим образом:
BlocProvider.of<ModulesBloc>(context).myString;
- Сохраните его в качестве переменной состояния; например, я могу объявить свой класс состояния следующим образом:
class ModulesState extends Equatable {
const ModulesState({required this.myString});
final String myString;
@override
List<Object> get props => [myString];
}
И получите доступ к нему в моем пользовательском интерфейсе следующим образом:
BlocBuilder<ModulesBloc, ModulesState>(
builder: (BuildContext context, ModulesState modulesState) {
modulesState.myString;
}
)
Существуют ли какие-либо проблемы с производительностью / стабильностью состояния при любом из вышеперечисленных подходов?
Спасибо!
Ответ №1:
Я не уверен, что существует абсолютный ответ, но я могу, по крайней мере, высказать свое мнение.
В блоке у вас есть 3 объекта: bloc , event , state .
Это state изменяемая часть, в то время как это bloc описание вашей проблемы (что state нужно излучать для каждого event ). Как таковая, неизменяемая переменная для описания вашей проблемы, по моему мнению, должна быть помещена внутрь bloc . Однако все, что может измениться, относится к state вашему блоку (так же, как и к state вашему виджету) и поэтому должно храниться в state .
Пример:
Вы хотите создать приложение, в котором вы можете устанавливать таймеры. В этом приложении у вас может быть несколько таймеров, каждый из которых будет идентифицирован a name .
В этом случае:
- ваше состояние будет представлять собой объект , содержащий вызываемую двойную переменную
timeCount, которая, например, будет увеличиваться каждые секунды. - У вас в блоке будет
finalполе под названиемname, которое необходимо будет задать при создании секундомера.
Интересно, что если вы хотите, чтобы блок также обрабатывал создание секундомера, у вас будет 2 состояния: первое пустое, второе с name и timeCount . Посмотрите, как естественно name стало изменяться и, следовательно, находится в state настоящем.
Комментарии:
1. Спасибо Lulupointu за хороший пример! Поэтому, в конечном счете, речь идет об «интерпретации» того, какие переменные изменчивы, а какие нет..
2. Ну, это не очень похоже на интерпретацию, вы всегда знаете, что есть что^^, Но если вы имели в виду определение, да, это так.
3. Да, это то, что я имел в виду. Итак, в качестве заключительной мысли, в моем случае, когда у меня есть список модулей, который обновляется (добавляется, удаляется и т. Д.), Я инициализирую его в классе блока и использую состояние для отражения изменений в нем. Но еще одна моя забота была связана с производительностью. Если есть намеки на это, это тоже было бы здорово!
4. Я не думаю, что производительность здесь имеет значение. Все это базовые операции, которые действительно быстры и в худшем случае асинхронны, поэтому они не должны вызывать никаких сбоев. Что касается вашего случая, я думаю, что вы делаете это правильно, но у вас не должно быть переменной, ссылающейся на ваш список в вашем блоке, вы должны использовать ее только для создания экземпляра вашего начального состояния (in
super). Если вам не понадобится ссылка на этот список в последний момент, и в этом случае это может быть спорным, я думаю, что все равно сохраню его в состоянии, но, как я уже сказал, это скорее вопрос последовательности и личных предпочтений