Accessing previous state using ref.state after a rebuild is not allowed

[AhmedLSayed9]

Note: This discussion meant to be a reference for understanding the reason of that restriction and offer alternative solutions.

Straight to an example:

@riverpod
int foo(FooRef ref) => 0;

@riverpod
class Bar extends _$Bar {
  bool _firstBuild = true;

  @override
  int build() {
    if(_firstBuild){
      state = 0;
      _firstBuild = false;
    }
    
    return state + ref.watch(fooProvider); //throw when re-build while state has value.
  }
}

Invalidating fooProvider will lead to an exception Tried to read the state of an uninitialized provider while state already has a value.
Reason: Accessing previous state using ref.state when the provider rebuild before using a setter again is not possible, That's because _debugDidSetState is set to false again when a provider rebuild. Is there a reason for that restriction?

Alternative solution:

@riverpod
class Bar extends _$Bar {
  @override
  int build() {
    state = 0;
    ref.listen(
      fooProvider,
      (previous, next) {
        state = state + ref.watch(fooProvider);
      },
      fireImmediately: true,
    );
    return state;
  }
}

This work fine but any rebuild of the provider will break the intended behavior (as state will back to 0). So, we should only use ref.listen without any other ref.watch which imo can mistakenly not to be followed.

[rrousselGit]

Sounds like a bug more than anything

[rrousselGit]

Oh wait, no this is desired.
"state" isn't really set at this point. You have the previous one, but it's supposed to represent the current one.

[rrousselGit]

Allowing state to return the previous value is possible, but I'm skeptical about enabling this.

It would mean that the number of times a provider rebuilds have an impact.
Meaning that if I update Riverpod to detect scenarios where a rebuild isn't necessary, that would be a breaking change.

Having a provider depend on its previous value also makes the code a lot of complex to reason with, and therefore less maintainable.

[AhmedLSayed9]

It would mean that the number of times a provider rebuilds have an impact.
Meaning that if I update Riverpod to detect scenarios where a rebuild isn't necessary, that would be a breaking change.

I don't understand this point tbh.

Based on what I understand from the code state doesn't lose its value anyway. If that's true, then accessing previous state is just allowing accessing state as long as it's initialized?

I think avoid setting _debugDidSetState back to false on rebuild will not affect reading state from other providers (using ref.read/ref.watch etc..) but will only enable reading previous state during a rebuild, which sound reasonable as the provider is considered initialized at that moment.

[rrousselGit]

Say your first snippet changed from rebuilding 5 times to rebuilding 3 times because Riverpod detected rebuilds that aren't necessary (such as none consumers watching the provider but the widgets aren't visible). Then that'd be breaking, because your provider would now render a different value when it finally becomes visible in the UI again.

[AhmedLSayed9]

oh Good point! pausing the provider will break that.

but I think that has nothing to do with enable accessing state as long as it's initialized but with the whole idea of depending on previous state. so, second snippet will break too.

Maybe the user has to disable pausing the provider in that case with the help of some lint that detect if state getter is used inside build.

[jeiea]

I think it is separate issue that the number of rebuilds of a provider can affect to the state. Library user can write problematic code with class field, without the provider state. I want to reference the previous state usually for state preservation.

[rrousselGit]

I don't agree. The state is always about the current state.

That's why when reading state, it can cause the provider to rebuild. Say the provider was paused and therefore state is currently out of date, then reading state causes the provider to rebuild, causing the getter to immediately return up-to-date state.

Using it to obtain the previous value is therefore conflicting with the purpose of that property.