点击上方蓝字关注我,知识会给你力量
最后一篇文章,我们在掌握了如何读取状态值,并知道如何根据不同场景选择不同类型的Provider,以及如何对Provider进行搭配使用之后,再来了解一下它的一些其它特性,看看它们是如何帮助我们更好的进行状态管理的。
Provider Modifiers
所有的Provider都有一个内置的方法来为你的不同Provider添加额外的功能。
它们可以为 ref 对象添加新的功能,或者稍微改变Provider的consume方式。Modifiers可以在所有Provider上使用,其语法类似于命名的构造函数。
final myAutoDisposeProvider = StateProvider.autoDispose<int>((ref) => 0);
final myFamilyProvider = Provider.family<String, int>((ref, id) => '$id');
目前,有两个Modifiers可用。
.autoDispose,这将使Provider在不再被监听时自动销毁其状态
.family,它允许使用一个外部参数创建一个Provider
一个Provider可以同时使用多个Modifiers。
final userProvider = FutureProvider.autoDispose.family<User, int>((ref, userId) async {
return fetchUser(userId);
});
.family
.family修饰符有一个目的:根据外部参数创建一个独特的Provider。family的一些常见用例是下面这些。
将FutureProvider与.family结合起来,从其ID中获取一个Message对象
将当前的Locale传递给Provider,这样我们就可以处理国际化
family的工作方式是通过向Provider添加一个额外的参数。然后,这个参数可以在我们的Provider中自由使用,从而创建一些状态。
例如,我们可以将family与FutureProvider结合起来,从其ID中获取一个Message。
final messagesFamily = FutureProvider.family<Message, String>((ref, id) async {
return dio.get('http://my_api.dev/messages/$id');
});
当使用我们的 messagesFamily Provider时,语法会略有不同。
像下面这样的通常语法将不再起作用。
Widget build(BuildContext context, WidgetRef ref) {
// Error – messagesFamily is not a provider
final response = ref.watch(messagesFamily);
}
相反,我们需要向 messagesFamily 传递一个参数。
Widget build(BuildContext context, WidgetRef ref) {
final response = ref.watch(messagesFamily('id'));
}
❝我们可以同时使用一个具有不同参数的变量。
例如,我们可以使用titleFamily来同时读取法语和英语的翻译。
❞@override Widget build(BuildContext context, WidgetRef ref) { final frenchTitle = ref.watch(titleFamily(const Locale('fr'))); final englishTitle = ref.watch(titleFamily(const Locale('en'))); return Text('fr: $frenchTitle en: $englishTitle'); }
参数限制
为了让families正确工作,传递给Provider的参数必须具有一致的hashCode和==。
理想情况下,参数应该是一个基础类型(bool/int/double/String),一个常数(Provider),或者一个重写==和hashCode的不可变的对象。
❝当参数不是常数时,更倾向于使用autoDispose
❞
你可能想用family来传递一个搜索字段的输入,给你的Provider。但是这个值可能会经常改变,而且永远不会被重复使用。这可能导致内存泄漏,因为在默认情况下,即使不再使用,Provider也不会被销毁。
同时使用.family和.autoDispose就可以修复这种内存泄漏。
final characters = FutureProvider.autoDispose.family<List<Character>, String>((ref, filter) async {
return fetchCharacters(filter: filter);
});
给family传递多重参数
family没有内置支持向一个Provider传递多个值的方法。另一方面,这个值可以是任何东西(只要它符合前面提到的限制)。
这包括下面这些类型。
tuple类型,类似Python的元组,https://pub.dev/packages/tuple
用Freezed或build_value生成的对象,https://pub.dev/packages/freezed
使用equatable的对象,https://pub.dev/packages/equatable
下面是一个对多个参数使用Freezed或equatable的例子。
@freezed
abstract class MyParameter with _$MyParameter {
factory MyParameter({
required int userId,
required Locale locale,
}) = _MyParameter;
}
final exampleProvider = Provider.autoDispose.family<Something, MyParameter>((ref, myParameter) {
print(myParameter.userId);
print(myParameter.locale);
// Do something with userId/locale
});
@override
Widget build(BuildContext context, WidgetRef ref) {
int userId; // Read the user ID from somewhere
final locale = Localizations.localeOf(context);
final something = ref.watch(
exampleProvider(MyParameter(userId: userId, locale: locale)),
);
...
}
.autoDispose
它的一个常见的用例是,当一个Provider不再被使用时,要销毁它的状态。
这样做的原因有很多,比如下面这些场景。
当使用Firebase时,要关闭连接并避免不必要的费用
当用户离开一个屏幕并重新进入时,要重置状态
Provider通过.autoDisposeModifiers内置了对这种使用情况的支持。
要告诉Riverpod当它不再被使用时销毁一个Provider的状态,只需将.autoDispose附加到你的Provider上即可。
final userProvider = StreamProvider.autoDispose<User>((ref) {
});
就这样了。现在,userProvider的状态将在不再使用时自动被销毁。
注意通用参数是如何在autoDispose之后而不是之前传递的--autoDispose不是一个命名的构造函数。
如果需要,你可以将.autoDispose与其他Modifiers结合起来。
final userProvider = StreamProvider.autoDispose.family<User, String>((ref, id) {
});
ref.keepAlive
用autoDispose标记一个Provider时,也会在ref上增加了一个额外的方法:keepAlive。
keep函数是用来告诉Riverpod,即使不再被监听,Provider的状态也应该被保留下来。
它的一个用例是在一个HTTP请求完成后,将这个标志设置为true。
final myProvider = FutureProvider.autoDispose((ref) async {
final response = await httpClient.get(...);
ref.keepAlive();
return response;
});
这样一来,如果请求失败,UI离开屏幕然后重新进入屏幕,那么请求将被再次执行。但如果请求成功完成,状态将被保留,重新进入屏幕将不会触发新的请求。
示例:当Http请求不再使用时自动取消
autoDisposeModifiers可以与FutureProvider和ref.onDispose相结合,以便在不再需要HTTP请求时轻松取消。
我们的目标是:
当用户进入一个屏幕时启动一个HTTP请求
如果用户在请求完成前离开屏幕,则取消HTTP请求
如果请求成功,离开并重新进入屏幕不会启动一个新的请求
在代码中,这将是下面这样。
final myProvider = FutureProvider.autoDispose((ref) async {
// An object from package:dio that allows cancelling http requests
final cancelToken = CancelToken();
// When the provider is destroyed, cancel the http request
ref.onDispose(() => cancelToken.cancel());
// Fetch our data and pass our `cancelToken` for cancellation to work
final response = await dio.get('path', cancelToken: cancelToken);
// If the request completed successfully, keep the state
ref.keepAlive();
return response;
});
异常
当使用.autoDispose时,你可能会发现自己的应用程序无法编译,出现类似下面的错误。
❝The argument type 'AutoDisposeProvider' can't be assigned to the parameter type 'AlwaysAliveProviderBase'
❞
不要担心! 这个错误是正常的。它的发生是因为你很可能有一个bug。
例如,你试图在一个没有标记为.autoDispose的Provider中监听一个标记为.autoDispose的Provider,比如下面的代码。
final firstProvider = Provider.autoDispose((ref) => 0);
final secondProvider = Provider((ref) {
// The argument type 'AutoDisposeProvider<int>' can't be assigned to the
// parameter type 'AlwaysAliveProviderBase<Object, Null>'
ref.watch(firstProvider);
});
这是不可取的,因为这将导致firstProvider永远不会被dispose。
为了解决这个问题,可以考虑用.autoDispose标记secondProvider。
final firstProvider = Provider.autoDispose((ref) => 0);
final secondProvider = Provider.autoDispose((ref) {
ref.watch(firstProvider);
});
provider状态关联与整合
我们之前已经看到了如何创建一个简单的Provider。但实际情况是,在很多情况下,一个Provider会想要读取另一个Provider的状态。
要做到这一点,我们可以使用传递给我们Provider的回调的ref对象,并使用其watch方法。
作为一个例子,考虑下面的Provider。
final cityProvider = Provider((ref) => 'London');
我们现在可以创建另一个Provider,它将消费我们的cityProvider。
final weatherProvider = FutureProvider((ref) async {
// We use `ref.watch` to listen to another provider, and we pass it the provider
// that we want to consume. Here: cityProvider
final city = ref.watch(cityProvider);
// We can then use the result to do something based on the value of `cityProvider`.
return fetchWeather(city: city);
});
这就是了。我们已经创建了一个依赖另一个Provider的Provider。
❝这个其实在前面的例子中已经讲到了,ref是可以连接多个不同的Provider的,这是Riverpod非常灵活的一个体现。
❞
FAQ
What if the value being listened to changes over time?
根据你正在监听的Provider,获得的值可能会随着时间的推移而改变。例如,你可能正在监听一个StateNotifierProvider,或者被监听的Provider可能已经通过使用ProviderContainer.refresh/ref.refresh强制刷新。
当使用watch时,Riverpod能够检测到被监听的值发生了变化,并将在需要时自动重新执行Provider的创建回调。
这对计算的状态很有用。例如,考虑一个暴露了todo-list的StateNotifierProvider。
class TodoList extends StateNotifier<List<Todo>> {
TodoList(): super(const []);
}
final todoListProvider = StateNotifierProvider((ref) => TodoList());
一个常见的用例是让用户界面过滤todos的列表,只显示已完成/未完成的todos。
实现这种情况的一个简单方法是。
创建一个StateProvider,它暴露了当前选择的过滤方法。
enum Filter {
none,
completed,
uncompleted,
}
final filterProvider = StateProvider((ref) => Filter.none);
做一个单独的Provider,把过滤方法和todo-list结合起来,暴露出过滤后的todo-list。
final filteredTodoListProvider = Provider<List<Todo>>((ref) {
final filter = ref.watch(filterProvider);
final todos = ref.watch(todoListProvider);
switch (filter) {
case Filter.none:
return todos;
case Filter.completed:
return todos.where((todo) => todo.completed).toList();
case Filter.uncompleted:
return todos.where((todo) => !todo.completed).toList();
}
});
然后,我们的用户界面可以监听filteredTodoListProvider来监听过滤后的todo-list。使用这种方法,当过滤器或todo-list发生变化时,用户界面将自动更新。
要看到这种方法的作用,你可以看一下Todo List例子的源代码。
❝这种行为不是特定于Provider的,它适用于所有的Provider。
例如,你可以将watch与FutureProvider结合起来,实现一个支持实时配置变化的搜索功能。
// The current search filter final searchProvider = StateProvider((ref) => ''); /// Configurations which can change over time final configsProvider = StreamProvider<Configuration>(...); final charactersProvider = FutureProvider<List<Character>>((ref) async { final search = ref.watch(searchProvider); final configs = await ref.watch(configsProvider.future); final response = await dio.get('${configs.host}/characters?search=$search'); return response.data.map((json) => Character.fromJson(json)).toList(); });
这段代码将从服务中获取一个字符列表,并在配置改变或搜索查询改变时自动重新获取该列表。
❞
Can I read a provider without listening to it?
有时,我们想读取一个Provider的内容,但在获得的值发生变化时不需要重新创建值。
一个例子是一个 Repository,它从另一个Provider那里读取用户token用于认证。
我们可以使用观察并在用户token改变时创建一个新的 Repository,但这样做几乎没有任何用处。
在这种情况下,我们可以使用read,这与listen类似,但不会导致Provider在获得的值改变时重新创建它的值。
在这种情况下,一个常见的做法是将ref.read传递给创建的对象。然后,创建的对象将能够随时读取Provider。
final userTokenProvider = StateProvider<String>((ref) => null);
final repositoryProvider = Provider((ref) => Repository(ref.read));
class Repository {
Repository(this.read);
/// The `ref.read` function
final Reader read;
Future<Catalog> fetchCatalog() async {
String token = read(userTokenProvider);
final response = await dio.get('/path', queryParameters: {
'token': token,
});
return Catalog.fromJson(response.data);
}
}
❝你也可以把ref而不是ref.read传给你的对象。
final repositoryProvider = Provider((ref) => Repository(ref)); class Repository { Repository(this.ref); final Ref ref; }
传递ref.read带来的唯一区别是,它略微不那么冗长,并确保我们的对象永远不会使用ref.watch。
❞
但是,永远不要像下面这样做。
final myProvider = Provider((ref) {
// Bad practice to call `read` here
final value = ref.read(anotherProvider);
});
如果你使用read作为尝试去避免太多的刷新重建,可以参考后面的FAQ
How to test an object that receives read as a parameter of its constructor?
如果你正在使用《我可以在不监听Provider的情况下读取它吗》中描述的模式,你可能想知道如何为你的对象编写测试。
在这种情况下,考虑直接测试Provider而不是原始对象。你可以通过使用ProviderContainer类来做到这一点。
final repositoryProvider = Provider((ref) => Repository(ref.read));
test('fetches catalog', () async {
final container = ProviderContainer();
addTearOff(container.dispose);
Repository repository = container.read(repositoryProvider);
await expectLater(
repository.fetchCatalog(),
completion(Catalog()),
);
});
My provider updates too often, what can I do?
如果你的对象被重新创建得太频繁,你的Provider很可能在监听它不关心的对象。
例如,你可能在监听一个配置对象,但只使用host属性。
通过监听整个配置对象,如果host以外的属性发生变化,这仍然会导致你的Provider被重新评估--这可能是不希望的。
这个问题的解决方案是创建一个单独的Provider,只公开你在配置中需要的东西(所以是host)。
应当避免像下面的代码一样,对整个对象进行监听。
final configProvider = StreamProvider<Configuration>(...);
final productsProvider = FutureProvider<List<Product>>((ref) async {
// Will cause productsProvider to re-fetch the products if anything in the
// configurations changes
final configs = await ref.watch(configProvider.future);
return dio.get('${configs.host}/products');
});
当你只需要一个对象的单一属性时,更应该使用select。
final configProvider = StreamProvider<Configuration>(...);
final productsProvider = FutureProvider<List<Product>>((ref) async {
// Listens only to the host. If something else in the configurations
// changes, this will not pointlessly re-evaluate our provider.
final host = await ref.watch(configProvider.selectAsync((config) => config.host));
return dio.get('$host/products');
});
这将只在host发生变化时重建 productsProvider。
通过这三篇文章,相信大家已经能熟练的对Riverpod进行使用了,相比package:Provider,Riverpod的使用更加简单和灵活,这也是我推荐它的一个非常重要的原因,在入门之后,大家可以根据文档中作者提供的示例来进行学习,充分的了解Riverpod在实战中的使用技巧。
向大家推荐下我的网站 https://xuyisheng.top/ 点击原文一键直达
专注 Android-Kotlin-Flutter 欢迎大家访问
往期推荐
本文原创公众号:群英传,授权转载请联系微信(Tomcat_xu),授权后,请在原创发表24小时后转载。
< END >
作者:徐宜生
更文不易,点个“三连”支持一下👇