Is a Context Provider good practice?

[MateusAmin]

This makes it easy to access the context in a Riverpod app. I can create a snackbar message (I see people just using snackbar providers instead), interface with the router, and have a async proof way of accessing the current context.

For example:

/// A context provider to be able to grab an up to date context from ref.
final contextProvider = StateProvider<BuildContext>((ref) {
  return StatelessElement(const Text('as'));
});

Future<void> main() async {
runApp(
      ProviderScope(
        child: MaterialApp.router(
          builder: (context, child) {
            return Consumer(
              builder: (context, ref, _) {
                ref.read(contextProvider.notifier).state = context;

                return child!;
              },
            );
          },
          routeInformationParser: enumRouter.routeInformationParser,
          routerDelegate: enumRouter.routerDelegate,
        ),
      ),
    ),
  );
}

Just include the builder in your widget tests.

[rrousselGit]

No this is a bad idea. Don't pass a BuildContext to your providers

[MateusAmin]

Thanks for the response! I hope open source is treating you well.

I saw this as an example of a pattern I could do instead:

#1331 (comment)