IN
плюс это решение не всегда будет срабатывать
Size: a a a
2021 April 17
PP
почему?
IN
а вдруг mounted будет false что тогда?
IN
плохое решение
ДЩ
не надо вызывать setState внутри initState
SL
Механизм EventLoop, тоси-боси
Event не воробей - улетит, не поймаешь
Event не воробей - улетит, не поймаешь
at
mounted будет false в большинстве случаев только когда уже виджет из дерева убрали
IN
но всеравно же может быть
IN
а это плохо
IN
так как решение становится бесполезным
IN
лучше поднапрячься и реализовать через тот же bloc
SL
А вдруг пользователь закроет приложение до того, как вернется ответ на твой запрос? Зря отправлял)
EE
да изи,
class SuperFutuer extends Future {
var _isCanceled = false;
void cancel(){
_isCanceled = true;
}
чудоМетодКоторыйВызываетКолбекПоВылолнениюФючи {
if (!_isCanceled) {
вызываем колбек
}
}
}
class SuperFutuer extends Future {
var _isCanceled = false;
void cancel(){
_isCanceled = true;
}
чудоМетодКоторыйВызываетКолбекПоВылолнениюФючи {
if (!_isCanceled) {
вызываем колбек
}
}
}
at
можно сделать присваивание всегда, а setState только когда mounted, он все равно только флаг вешает, что нужно сделать ребилд. а если виджет будет вешать в дерево, все равно будет ребилд
SL
Едва ли это можно назвать отменой, но окей
EE
ну это отмена)
EE
вообще у нас в iOS есть таск, который вот так и работает)
SL
Он тоже в случае отмены доработает до конца, просто всем будет пофиг на результат?
SL
Это не байт ес чо, пробую копать iOS потихоньку, интересно стало)
n_
Переход от future к колбэкам это очень глупо