Что ждёт Flutter в будущем

[beduin01]

Какие State менеджеры позволяют максимально сократить объем кода и писать вместо двух классов один? GetX к сожалению больше не поддерживается.

[neoxack]

Mobx

[rafuck]

Откуда информация о том, что getx не поддерживается?

[beduin01]

Два месяца назад у них в issues висела эта тема. Буду рад если проект будет жить.

P.S. Посмотрел только что -- вижу на минувшей неделе появились новые коммиты.

[Daseron]

Riverpod?

[PackRuble]

Мне тоже нравится этот вариант в некоторой степени. Но без должной сноровки может сильно развязать руки))

[Daseron]

Можно поподробнее? Просто интересно стало.

[PackRuble]

Riverpod действительно может сократить код, но если не придерживаться чёткого архитектурного решения, то всё превратится в тыкву и будет Circular dependencies. Тот же bloc имеет некоторые паттерны, объясняющие, как его нужно использовать.

[Gorniv]

Странный подход к выбору State Managment, выбирать нужно от задач гибкости решения, я рекомендую работать с BLoC, а для кодо-генерации использовать https://marketplace.visualstudio.com/items?itemName=gornivv.vscode-flutter-files с custom template под свой проект.

[beduin01]

А почему странный? Я реально так и не понял зачем нужно два класса, когда можно одним обойтись. Получается код ради когда.

[Pasher]

В BLoC есть очень удобный Cubit. Если речь о простых типах данных, то в один класс все умещается

[PackRuble]

Честно говоря, с Wonderous они перемудрили. 6гб озу, snap 845. С этими вводными я вижу лаганое свистоперделочное приложение, в котором глаза вытекают от всех крученых-перекрученых анимаций с периодическими лагами при прогрузке новых маршрутов/зон. Я не могу понять, что оно демонстрирует?

За перевод и личное мнение спасибо!