Using syncfuture here causes exceptions when hot-reloading or refreshing a flutter app in the browser (and only the browser, I think because of the direct access to the browser history).
I see using Future.value() is commented-out here which I assume may be due to a correctness issue at-worst, and a performance optimization at-best. I'm guessing the latter.
There's rarely a reason to use sync futures in dart, imo. They come with many more dangers than advantages as they circumvent the natural event ordering that the event loop guarantees (which risks correctness in many cases). I just don't use them, personally. See here for more info.
Error: 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
in a widget life-cycle, such as but not limited to:
- build
- initState
- dispose
- didUpdateWidget
- didChangeDepedencies
Modifying a provider inside those life-cycles is not allowed, as it could
lead to an inconsistent UI state. For example, two widgets could listen to the
same provider, but incorrectly receive different states.
To fix this problem, you have one of two solutions:
- (preferred) Move the logic for modifying your provider outside of a widget
life-cycle. For example, maybe you could update your provider inside a button's
onPressed instead.
- Delay your modification, such as by encasuplating the modification
in a `Future(() {...})`.
This will perform your update after the widget tree is done building.
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 288:49 throw_
packages/flutter_riverpod/src/framework.dart 343:7 [_debugCanModifyProviders]
packages/riverpod/src/framework/element.dart 487:34 <fn>
packages/riverpod/src/framework/element.dart 158:7 setState
packages/riverpod/src/state_provider/base.dart 141:9 <fn>
packages/state_notifier/state_notifier.dart 225:23 set state
packages/riverpod/src/state_controller.dart 15:31 set state
packages/riverpod_navigator_core/src/navigator.dart 95:39 <fn>
packages/riverpod_navigator_core/src/navigator.dart 100:61 navigate
packages/riverpod_navigator/src/routeDelegate.dart 38:22 setNewRoutePath
packages/flutter/src/widgets/router.dart 1280:12 setInitialRoutePath
packages/flutter/src/widgets/router.dart 714:32 <fn>
dart-sdk/lib/_internal/js_dev_runtime/patch/async_patch.dart 84:54 runBody
dart-sdk/lib/_internal/js_dev_runtime/patch/async_patch.dart 123:5 _async
packages/flutter/src/widgets/router.dart 710:15 <fn>
packages/flutter/src/foundation/synchronous_future.dart 41:39 then
packages/flutter/src/widgets/router.dart 705:59 [_processRouteInformation]
packages/flutter/src/widgets/router.dart 583:7 restoreState
packages/flutter/src/widgets/restoration.dart 912:5 [_doRestore]
packages/flutter/src/widgets/restoration.dart 898:7 didChangeDependencies
packages/flutter/src/widgets/router.dart 653:11 didChangeDependencies
packages/flutter/src/widgets/framework.dart 5237:11 [_firstBuild]
packages/flutter/src/widgets/framework.dart 5062:5 mount
packages/flutter/src/widgets/framework.dart 3971:15 inflateWidget
packages/flutter/src/widgets/framework.dart 3708:18 updateChild
packages/flutter/src/widgets/framework.dart 5111:16 performRebuild
packages/flutter/src/widgets/framework.dart 4805:7 rebuild
packages/flutter/src/widgets/framework.dart 5068:5 [_firstBuild]
packages/flutter/src/widgets/framework.dart 5062:5 mount
packages/flutter/src/widgets/framework.dart 3971:15 inflateWidget
packages/flutter/src/widgets/framework.dart 3708:18 updateChild
packages/flutter/src/widgets/framework.dart 5111:16 performRebuild
packages/flutter/src/widgets/framework.dart 4805:7 rebuild
packages/flutter/src/widgets/framework.dart 5068:5 [_firstBuild]
... Huge stack of flutter builds, mounts, rebuilds, etc.
Using syncfuture here causes exceptions when hot-reloading or refreshing a flutter app in the browser (and only the browser, I think because of the direct access to the browser history).
I see using
Future.value()is commented-out here which I assume may be due to a correctness issue at-worst, and a performance optimization at-best. I'm guessing the latter.There's rarely a reason to use sync futures in dart, imo. They come with many more dangers than advantages as they circumvent the natural event ordering that the event loop guarantees (which risks correctness in many cases). I just don't use them, personally. See here for more info.