Flutter Provider's state error
一个应该很常见的场景，一个接口请求list，初期是空的，请求成功后，需要更新list，然后UI会重新build，但是这个时候，如果你想在请求的时候，手动设置 state 为 loading，表示正在请求，这个时候就会报错。
使用的技术栈：
- riverpodhooks
- riverpod_annotation
- freezed
- flutter_riverpod
Tried to modify a provider while the widget tree was building.
If you are encountering this error, chances are you tried to modify a provider
以后会尽量用日语来写，为了练习日语。
EN
This error happens when you try to change a provider’s state inside a widget’s life cycle (for example, inside build, initState, dispose, didUpdateWidget, or didChangeDependencies). Riverpod (or Flutter’s provider package) requires that you not directly modify state during these phases, because it can lead to inconsistent or unintended UI states.
Why this happens
In Flutter, widgets can rebuild multiple times for all kinds of reasons (e.g., a parent changed, you rotated the device, etc.). If you modify the state in the middle of a build:
- You risk triggering more rebuilds before the UI has finished its current update.
- You could cause inconsistent states if multiple widgets depend on the same provider but rebuild at slightly different times.
As a result, Riverpod/Provider actively prevents you from modifying a provider during these critical moments and throws the error you’re seeing.
How to fix
1. Move provider modifications outside widget life cycles
The simplest and often best solution is to initiate the provider update in response to a user action or an asynchronous event (like an API call), rather than in build or initState. For example, call:
ElevatedButton(
onPressed: () {
// This is allowed because it’s in a callback
ref.read(yourProvider.notifier).updateSomething();
},
child: Text('Update Provider'),
);This way, the provider is updated after the build, not during it.
2. Use a post-build callback to delay the update
If you truly need to modify a provider as soon as the widget builds (for example, you need an initial fetch), you can schedule the update after the first build completes by using a callback such as Future(() { ... }) or WidgetsBinding.instance.addPostFrameCallback. For instance:
void initState() {
super.initState();
// Schedules the provider update to run AFTER the current frame
WidgetsBinding.instance.addPostFrameCallback((_) {
ref.read(yourProvider.notifier).updateSomething();
});
}This tells Flutter to wait until the current widget tree build is finished before modifying the provider’s state, which avoids the error.
Recap
- Never call
ref.read(...)orcontext.read(...)to change a provider directly insidebuild,initState, or other life-cycle methods. - Instead, use an external event like a button press, or schedule the update to happen after the current build (via a future or
addPostFrameCallback).
Following these guidelines ensures your app state remains consistent and helps avoid tricky rebuild and state management issues.
JP
FlutterやRiverpodのProviderを使用して開発している際に、
「Tried to modify a provider while the widget tree was building…」という
Errorが出る場合があります。
これはWidgetのライフサイクル(Life-cycle)――
たとえばbuild・initState・dispose・didUpdateWidget・didChangeDependenciesなどのタイミング(Timing)で
Providerの状態(State)を直接変更(へんこう)してしまうと発生する問題です。
なぜこのErrorが起きるのか
Widgetの描画（build）処理は頻繁に呼ばれます。
その途中でProviderを更新すると、
ほかのWidgetとの整合が崩れ、
画面（UI(User Interface))が不正な状態になる恐れがあります。
そのため、内部で再描画の制御を行っている
RiverpodやProviderは、
こうした誤用が起きた際に
警告(Warning)としてこのErrorを投げてくれます。
対策(たいさく)
-
（推奨）ライフサイクル内(ない)での変更(へんこう)を避(さ)ける
- たとえば
onPressedなど、ユーザー(User)の操作や
非同期(Asynchronous)のイベント(Event)が完了した後に
Providerを更新するように設計しましょう。
// ButtonのonPressed内でProviderを更新 ElevatedButton( onPressed: () { ref.read(yourProvider.notifier).updateSomething(); }, child: Text('Update Provider'), ); - たとえば
-
どうしても初期化(しょきか)で設定(せってい)が必要(ひつよう)な場合(ばあい)
initStateやdidChangeDependenciesなどですぐにProviderを更新したい場合は、
ビルド(Build)が完了してから実行するよう
WidgetsBinding.instance.addPostFrameCallbackなどを使い、
更新のタイミングを遅らせる方法があります。
void initState() { super.initState(); WidgetsBinding.instance.addPostFrameCallback((_) { // ビルド完了後にProviderを更新 ref.read(yourProvider.notifier).updateSomething(); }); }
まとめ
- Providerの状態を直接変(か)える処理は、
build・initState・disposeなど
Widgetのライフサイクル内で行うと
UIが不安定になる恐れがあり、Errorが発生します。 - 基本はユーザー操作や非同期処理(しょり)の完了後(あと)など、
ライフサイクル(Life-cycle)の外でProviderを更新するよう注意しましょう。 - 初期化時やどうしても必要(ひつよう)なタイミングでは、
WidgetsBinding.instance.addPostFrameCallbackやFuture(() { … })を使い、
一度ビルドが完了してから更新することで
安全に状態を保つことができます。
こうした対策を取ることで、
「Tried to modify a provider while the widget tree was building…」という
Errorを回避でき、
安定したUIを保つことができます。
JP 2
RiverpodのHook(Hook)を使用して開発している場合でも、
基本は前述の注意点(Point)と同じです。
つまり、Widgetのbuild中やライフサイクル(Life-cycle)の処理の途中で、
Providerを直接更新(こうしん)しないようにすることが大切です。
HookConsumerWidgetの場合
RiverpodとFlutterのHookを組み合わせ(Combine)て使う際は、
画面(Screen/Page)を定義する時にHookConsumerWidgetを継承(Inherit)すると便利です。
以下の例では、
useEffectを利用(Use)して、初回ビルド完了(Complete)後に
Providerの状態を変更(Update)している例です。
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
// なにかしらのProviderを定義（StateNotifierProviderなど）
final yourProvider = StateNotifierProvider<YourNotifier, YourState>((ref) {
return YourNotifier();
});
class YourNotifier extends StateNotifier<YourState> {
YourNotifier() : super(YourState());
void updateSomething() {
// 状態を更新する処理
}
}
class YourState {
// 状態管理のためのプロパティなど
}
class ExamplePage extends HookConsumerWidget {
const ExamplePage({Key? key}) : super(key: key);
Widget build(BuildContext context, WidgetRef ref) {
// 状態を監視
final state = ref.watch(yourProvider);
// build完了後に一度だけProviderを更新したい場合などにuseEffectを使用
useEffect(() {
Future.microtask(() {
ref.read(yourProvider.notifier).updateSomething();
});
// dispose時の処理が必要なければnull
return null;
}, []);
return Scaffold(
appBar: AppBar(
title: Text('HookConsumerWidget Example'),
),
body: Center(
child: Text('State: $state'),
),
);
}
}ポイント
-
buildの中で直接Providerを更新しない
- かわりに
useEffect・Future(() { … })・WidgetsBinding.instance.addPostFrameCallbackなどを使って
ビルド(Build)が終わった後にProviderの状態を変更します。
- かわりに
-
ユーザー(User)の操作やイベント(Event)に応じて更新する
onPressedなどのコールバック(Callback)の中で更新する分には問題ありません。
まとめ
- HookConsumerWidgetを使った場合も、
ライフサイクル（buildなど）の途中で
Providerを変更しないように注意することが重要です。 useEffectを使うことで初回ビルド完了後(あと)にProviderを更新でき、
不要なタイミング(Timing)での変更を避けられます。- ユーザー(User)の操作に応じて状態を変更する処理も同様で、
onPressedなどビルドの外のタイミングで更新すれば安全に状態を保てます。
これらを徹底することで、
「Tried to modify a provider while the widget tree was building…」というErrorの発生を防ぎ、
安定したUI(User Interface)を構築(Build)できます。