Riverpod Migration to Notifier

[YukiAttano]

I may have misused Riverpod the whole time but i am now missing an important feature in the Notifier class which maybe someone might help me to avoid.

In short: i can't access a valid state during initialization (e.g. the first run of) build().

In long:
The following is a basic implementation of a Snapshot my Notifier are working with.

class SomeSnapshot {
  final List<String> stuff;
  final bool loading;
  final String lastFilter;

  const SomeSnapshot({required this.stuff, required this.loading, required this.lastFilter});

  const SomeSnapshot.init({bool loading = true}) : this(stuff: const [], loading: loading, lastFilter: "");

  SomeSnapshot copyWith({List<String>? stuff, bool? loading, String? lastFilter}) {
    return SomeSnapshot(
      stuff: stuff ?? this.stuff,
      loading: loading ?? this.loading,
      lastFilter: lastFilter ?? this.lastFilter,
    );
  }
}

This is my StateNotifier, which is considered deprecated with the new Notifier Class

class SomeNotifier extends StateNotifier<SomeSnapshot> {
  SomeNotifier() : super(const SomeSnapshot.init()) {
    unawaited(_init());
  }

  Future<void> _init() async {
    await requestStuff(force: true);
  }

  Future<void> requestStuff({bool force = false, String filter = ""}) async {
    if (!force && state.loading) return;

    state = state.copyWith(loading: true);

    // request stuff with filter
    List<String> result = ["Some", "loaded", "content", "from", "remote"];

    state = state.copyWith(stuff: result, lastFilter: filter, loading: false);
  }
}

This is my approach in implementing the new Notifier, which will never work as i have to access the current 'state'.
The current state does not exist during initialization.

class SomeNewNotifier extends Notifier<SomeSnapshot> {
  @override
  SomeSnapshot build() {
    unawaited(_init());

    return const SomeSnapshot.init(loading: true);
  }

  Future<void> _init() async {
    // Throws Exception, as requestStuff accesses state which is not yet initialized
    await requestStuff(force: true);
  }

  Future<void> requestStuff({bool force = false, String filter = ""}) async {
    if (!force && state.loading) return;

    state = state.copyWith(loading: true);

    // request stuff with filter 
    List<String> result = ["Some", "loaded", "content", "from", "remote"];

    state = state.copyWith(stuff: result, lastFilter: filter, loading: false);
  }
}

Up to now, from different workarounds, this one seems to be the most fitting (not yet tested) but doesn't feel right.
It would require me to write wrapper that either pass the Snapshot.init() for initialization or the current 'state' in all other cases.

  // Option 1
  Future<void> requestStuff_1({required SomeSnapshot current, bool force = false, String filter = ""}) async {
    if (!force && current.loading) return;

    state = current.copyWith(loading: true);

    // request stuff with filter
    List<String> result = ["Some", "loaded", "content", "from", "remote"];

    state = current.copyWith(stuff: result, lastFilter: filter, loading: false);
  }

[rrousselGit]

You should be using AsyncNotifier here :)

But you can use "stateOrNull" inside Notifier

[YukiAttano]

Thanks for the quick answer, unfortunately this will change the logic from "i do always have a state that my UI can work with" to second layer of abstraction that 'could' be in a 'loading' or 'error' state that i had to handle somehow.
Those states are meant to be in my Snapshot, not around of it.

It also adds some extra code from

var snap = ref.watch(placelessProvider);

to

var snap = ref.watch(placelessProvider).unwrapPrevious().valueOrNull;

(which i will likely oversee in many places, causing weird bugs in the future)
and additionally add a possible 'null' value for my whole Snapshot.

Having 'null' as a value of my Snapshot is not always the same as alternatively using Snapshot.init() to replace them in that case.
Even if my Snapshot.init() looks like the perfect replacement, it moves the logic of my initial state out of my notifier and into the data class that should be handled by them.

I tested my approach, writing some wrapper and passing my initial state into my request() function which looks more practical for me than using an AsyncValue.

I guess i will come back to this if i update my heavier notifiers.

[YukiAttano]

You should be using AsyncNotifier here :)

But you can use "stateOrNull" inside Notifier

Maybe i got something hardly wrong.
Is there any need to migrate from StateNotifier to Notifier?
e.g. from StateNotifier.autoDispose to a AutoDisposeNotifier?

Up to now, only a lot of Ref Classes are deprecated.

I am asking, as i have written a "GenericNotifier" which bundles my exception handling.
The new Notifier Class has no public parent class which i could depend on, to migrate.