в идеале придерживаться какого-то одного подхода к стейт менеджменту.
Смотря для чего
Ну у меня есть true false поле которое будет показываться скрол вниз в листвю но в дебаг режиме setState немного лагает(в релизе норм)
Ты при скролле setState делаешь?
Всё зависит от уровня логики
Нет, когда оно не внизу и когда достиг вниз тоесть два раза
Ну, к бизнес-логики это не относится, так что можно и setState
лучше в лисенер скролла прописать эвент блока
Ну ты судя по всему при скролле делаешь сетстейт, то есть перестраиваешь скролл
Я не юзаю setState при каждом изменение пикселя, только когда оно достиг вниз и не внизу тоесть только два раза
поддержу данное опасение
Я не про каждый пиксель а вообще... Глупо в зависимости от состояния объекта обновлять его состояние
есть особо всратый вариант решения данной проблемы (вкидываю ради шутки) - использовать parentScrollController чтобы запихнуть твой скролл контроллер в контекст и уже в ребенке получить его из контекста и навесить listener
А теперь понял о чём ты, да ты прав
Блок головного мозга) (Без обид, я когда что-то новое для себя открываю тоже везде непоподя использую)
попробуй кубит удобно что ваще
его нужно очень аккуратно готовить....
зачем? Это же тот же вельюнотифаер
Зачем он вообще нужен?! У блока хотя бы идеология есть
ну незнаю, вроде ничего сложного а по поводу valueNotifier то половина флаттера на нем построена
в модульную архитектуру вписывается как никто, нет любви мозга с эвентами, дергаешь методы как надо + это стейтменеджер
добавил на экспорт модели евентов и все, свободно используй в других модулях
а тут они не нужны)
Что в нём от менеджмента стейта то? То что глобально он уведомляет о своем создании/удалении и изменении состояния?
я к тому что аргумент про модульность хромает
а что еще от менеджера состояний еще нужно в работе мобильных сервисов?_)
Обсуждают сегодня