Flutter 为什么 ref.watch(otherProvider.stream) 在 Riverpod 2.x 中被弃用并且将在 3.x 中被删除

.stream修饰符已经被弃用，因为它几乎总是被糟糕地使用，导致复杂的难以发现的错误.

您在这个问题中给出的片段也面临着同样的问题.您提供的代码片段有一个错误:

@riverpod
Stream<PlaceDetails?> selectedPlace(SelectedPlaceRef ref) {
    final placeId = ref.watch(selectedPlaceIdProvider);
    if (placeId != null) {
        return ref.watch(placeProvider(placeId).stream);
    }

    return const Stream.empty();
}

在这段代码中，.stream的使用引入了一个问题，现在selectedPlace的行为取决于读取提供程序的顺序.

就说你做到了:

void main() async {
  final container = ProviderContainer();
  final place = await container.read(placeProvider(123).future);

  container.read(selectedPlaceIdProvider.notifier).state = 123;
  container.listen(selectedPlaceProvider, (_, value) {
    print('Place $value');
  });
}

Then in this scenario, you'll find that the print is in fact never reached, and selectedPlace never emits anything.
But if you were to comment out the final place = await container.read(placeProvider(123).future); line, then your code would "work".

这实际上意味着使用.stream引入了竞争条件.除非您熟悉这个问题，否则很难发现它，并且可能导致严重的可维护性问题.

另一方面，.stream并不会给Riverpod增加太多价值.没有.stream，你已经可以做任何事情了.

引入弃用的ChangeLog为您的用法提供了替代语法https://github.com/rrousselGit/riverpod/blob/master/packages/riverpod/CHANGELOG.md#230

在您的例子中，您可以重构selectedPlaceProvider以:

@riverpod
Future<PlaceDetails?> selectedPlace(SelectedPlaceRef ref) {
    final placeId = ref.watch(selectedPlaceIdProvider);
    if (placeId == null) return null;

    return ref.watch(placeProvider(placeId).future);
}

This snippet behave like you would expect the .stream variant to behave. In that scenario, selectedPlace will update whenever either placeProvider or selectedPlaceIdProvider update.
But at the same time, this doesn't involve the race-condition problem discussed above. That main wrote previously would now work as expected.