Тег: dart

Этот сбой означает, что вы прочитали late-поле до того, как ему что-либо присвоили. Инициализируйте его синхронно в initState или откажитесь от late и смоделируйте асинхронное значение как nullable-состояние.

Оператор ! наткнулся на null во время выполнения. Замените его на ?. и ?? для значения по умолчанию или защитите явной проверкой на null, вместо того чтобы утверждать значение, которого не было.

Создайте постоянную оболочку с вложенными маршрутами через ShellRoute и StatefulShellRoute, а затем настройте deep links на основе путей, которые восстанавливают весь стек страниц. Полная конфигурация для Android и iOS, а также подводные камни, ломающие стек возврата.

Считайте всё необходимое из context до await, а затем защитите продолжение через if (context.mounted) return. Здесь полный паттерн, правило линтера, которое его требует, и краевые случаи, которые оно не ловит.

Руководство с зафиксированными версиями для перевода устаревшего приложения Flutter 2.x на актуальный выпуск Flutter 3.x, где миграция на sound null safety является жёстким барьером: почему нужен путь в два шага через Dart 2.19, что делает dart migrate и что ломается по дороге.

Пошаговая миграция с пакета provider на Riverpod 3.x в реальном приложении Flutter: ChangeNotifierProvider на Notifier, MultiProvider на ProviderScope, context.watch на ref.watch, ProxyProvider на композицию через ref.watch, плюс подводные камни с равенством и жизненным циклом. Проверено на Flutter 3.27.1, Dart 3.11, provider 6.1.5, flutter_riverpod 3.3.1.

Используйте FutureBuilder или StreamBuilder для самодостаточного, одноразового асинхронного виджета. Переходите на AsyncValue из Riverpod, как только результат становится общим, кешируется или мутирует. Здесь решение, подводные камни и исполняемый код для обоих. Проверено на Flutter 3.44 и flutter_riverpod 3.3.1.

Этот сбой означает, что WidgetRef использовали после того, как его виджет покинул дерево, обычно в асинхронном колбэке. Прочитайте всё нужное до await и защитите проверкой mounted.

Этот сбой означает, что вы вызвали context.of() после того, как виджет покинул дерево, обычно в асинхронном callback или в dispose(). Захватите значение до await или в didChangeDependencies().

FutureBuilder заново выполняет асинхронную работу при каждой перестройке родителя, потому что вы создали Future внутри build. Перенесите его в State.initState (или мемоизируйте), и FutureBuilder будет переиспользовать тот же Future. Здесь объяснение причины, воспроизводимый пример и каждый кусачий вариант.