a hacky way to set state using provider, ie. ref.read(someProvider.notifier).state = someState;

[nyck33]

Widget build(BuildContext context) {
    ref.read(userProvider.notifier).state = user;  //here!
    final checkuser = ref.read(userProvider.notifier).state;
    return Scaffold(
      //appBar: AppBar(),
      endDrawer: MyDrawer(),
      body: FirstScreen(user: user),
      bottomNavigationBar: MyBottomNavigationBar(selectedIndex: 0),
    );
  }

But now I heard the state is actually just ref.read(userProvider) and to call methods in the StateNotifier, use ref.read(userProvider.notifier).

And to also use watch rather than read for easier debugging later.

Is it safe to say, these calls should be made in the same place in the code as setState(){} would be?
I'm having a super difficult time with the transition from login to homescreen where I'm trying to initialize the state of my user and UI based on the login data.

If possible, please make some documentation on this specific case. I have a Reddit post: https://www.reddit.com/r/flutterhelp/comments/quypl5/riverpod_when_do_you_use_provider_to_set_state/?utm_source=share&utm_medium=web2x&context=3

[rrousselGit]

Doing this inside build is a really bad idea.

It sounds like your architecture is not correct. You should have a better place for modifying this provider than doing it here.

[nyck33]

I read more of your answers on uni-directional data flow and now get it. I see how it's a bad idea in build but ok in a function called on some "action" performed on a UI by a user.
Thanks.

[alyyasser]

I read more of your answers on uni-directional data flow

where can i read those?

[alyyasser]

im currently migrating my project to riverpod 1.0.0, and i used similar code with OP. my code:

  Widget build(BuildContext context, WidgetRef ref) {
    SchedulerBinding.instance?.addPostFrameCallback((_) {
      ref.read(searchWordProvider.state).state = null;
    });
    ...
  }

my intention was, to reset the state. any suggestion for better approach on this?

[TimWhiting]

For your use case have you tried using an autodispose provider?

[alyyasser]

sorry for late reply.

For your use case have you tried using an autodispose provider?

yes, i do. but because my providers are mostly reusable across my widgets, the dispose doesn't triggered the way i wanted. or maybe i use it 'wrong'? i declare my providers as global variables by the way.