website/docs/how_to/eager_initialization.mdx
import { Link } from "/src/components/Link"; import { AutoSnippet } from "/src/components/CodeSnippet"; import consumerExample from "!!raw-loader!./eager_initialization/consumer_example.dart"; import asyncConsumerExample from "!!raw-loader!./eager_initialization/async_consumer_example.dart"; import requireValue from "./eager_initialization/require_value";
All providers are initialized lazily by default. This means that the provider is only initialized when it is first used. This is useful for providers that are only used in certain parts of the application.
Unfortunately, there is no way to flag a provider as needing to be eagerly initialized due to how Dart works (for tree shaking purposes). One solution, however, is to forcibly read the providers you want to eagerly initialize at the root of your application.
The recommended approach is to simply "watch" a provider in a Consumer placed right under your ProviderScope:
:::note Consider putting the initialization consumer in your "MyApp" or in a public widget. This enables your tests to use the same behavior, by removing logic from your main. :::
No, this is not the case.
In the sample given above, the consumer responsible for eagerly initializing
is a separate widget, which does nothing but return a child.
The key part is that it returns a child, rather than instantiating MaterialApp itself.
This means that if _EagerInitialization ever rebuilds, the child variable
will not have changed. And when a widget doesn't change, Flutter doesn't rebuild it.
As such, only _EagerInitialization will rebuild, unless another widget is also listening to that provider.
You can handle loading/error states as you normally would in a Consumer.
Your _EagerInitialization could check if a provider is in a "loading" state,
and if so, return a CircularProgressIndicator instead of the child:
Rather than trying to have your provider not expose an AsyncValue, you can
instead have your widgets use AsyncValue.requireValue.
This will read the data without having to do pattern matching. And in case a bug slips through,
it will throw an exception with a clear message.
<AutoSnippet {...requireValue} />
:::note
Although there are ways to not expose the loading/error states in those cases (relying on scoping),
it is generally discouraged to do so.
The added complexity of making two providers and using overrides is not worth the trouble.
:::