前面一篇文章,我们了解了如何正确的去读取状态值,这一篇,我们来了解下不同的Provider都有哪些使用场景。这篇文章,我们将真正的深入了解,如何在不同的场景下,选择合适的种类的Provider,以及这些不同类型的Provider,都有哪些作用。
Provider有多种类型的变种,可以用于多种不同的使用场景。
在所有这些Provider中,有时很难理解何时使用一种Provider类型而不是另一种。使用下面的表格,选择一个适合你想提供给Widget树的Provider。
Provider Type | Provider Create Function | Example Use Case |
---|---|---|
Provider | Returns any type | A service class / computed property (filtered list) |
StateProvider | Returns any type | A filter condition / simple state object |
FutureProvider | Returns a Future of any type | A result from an api call |
StreamProvider | Returns a Stream of any type | A stream of results from an API |
StateNotifierProvider | Returns a subclass of StateNotifier | A complex state object that is immutable except through an interface |
ChangeNotifierProvider | Returns a subclass of ChangeNotifier | A complex state object that requires mutability |
虽然所有的Provider都有他们的目的,但ChangeNotifierProviders不被推荐用于可扩展的应用程序,因为它存在可变的状态问题。它存在于flutter_riverpod包中,以提供一个简单的从package:provider的迁移组件,并允许一些flutter特定的使用情况,如与一些Navigator 2包的集成。
Provider是所有Providers中最基本的。它返回了一个Value... 仅此而已。
Provider通常用于下面的场景。
当与ref.watch结合时,Provider是一个强大的工具,用于缓存同步操作。
一个典型的例子是过滤一个todos的列表。由于过滤一个列表的成本较高,我们最好不要在我们的应用程序每次需要重新渲染的时候,就过滤一次我们的todos列表。在这种情况下,我们可以使用Provider来为我们做过滤工作。
为此,假设我们的应用程序有一个现有的StateNotifierProvider,它管理一个todos列表。
class Todo {
Todo(this.description, this.isCompleted);
final bool isCompleted;
final String description;
}
class TodosNotifier extends StateNotifier<List<Todo>> {
TodosNotifier() : super([]);
void addTodo(Todo todo) {
state = [...state, todo];
}
// TODO add other methods, such as "removeTodo", ...
}
final todosProvider = StateNotifierProvider<TodosNotifier, List<Todo>>((ref) {
return TodosNotifier();
});
在这里,我们可以使用Provider来管理一个过滤后的todos列表,只显示已完成的todos。
final completedTodosProvider = Provider<List<Todo>>((ref) {
// We obtain the list of all todos from the todosProvider
final todos = ref.watch(todosProvider);
// we return only the completed todos
return todos.where((todo) => todo.isCompleted).toList();
});
有了这段代码,我们的用户界面现在能够通过监听 completedTodosProvider来显示已完成的todos列表。
Consumer(builder: (context, ref, child) {
final completedTodos = ref.watch(completedTodosProvider);
// TODO show the todos using a ListView/GridView/...
});
有趣的是,现在的过滤后的列表是被缓存的。这意味着在添加/删除/更新todos之前,已完成的todos列表不会被重新计算,即使我们多次读取已完成的todos列表。
请注意,当todos列表发生变化时,我们不需要手动使缓存失效。由于有了ref.watch,Provider能够自动知道何时必须重新计算结果。
Provider的一个独特之处在于,即使Provider被重新计算(通常在使用ref.watch时),它也不会更新监听它的widgets/providers,除非其值发生了变化。
一个真实的例子是启用/禁用一个分页视图的上一个/下一个按钮。
在我们的案例中,我们将特别关注 "上一页 "按钮。这种按钮的一个普通的实现,是一个获得当前页面索引的Widget,如果该索引等于0,我们将禁用该按钮。
这段代码可以是这样。
final pageIndexProvider = StateProvider<int>((ref) => 0);
class PreviousButton extends ConsumerWidget {
const PreviousButton({Key? key}): super(key: key);
@override
Widget build(BuildContext context, WidgetRef ref) {
// if not on first page, the previous button is active
final canGoToPreviousPage = ref.watch(pageIndexProvider) != 0;
void goToPreviousPage() {
ref.read(pageIndexProvider.notifier).update((state) => state - 1);
}
return ElevatedButton(
onPressed: canGoToPreviousPage ? null : goToPreviousPage,
child: const Text('previous'),
);
}
}
这段代码的问题是,每当我们改变当前页面时,"上一页 "按钮就会重新Build。在理想的世界里,我们希望这个按钮只在激活和停用之间变化时才重新build。
这里问题的根源在于,我们正在计算用户是否被允许在 "上一页 "按钮中直接转到上一页。
解决这个问题的方法是把这个逻辑从widget中提取出来,放到一个Provider中。
final pageIndexProvider = StateProvider<int>((ref) => 0);
// A provider which computes whether the user is allowed to go to the previous page
final canGoToPreviousPageProvider = Provider<bool>((ref) {
return ref.watch(pageIndexProvider) != 0;
});
class PreviousButton extends ConsumerWidget {
const PreviousButton({Key? key}): super(key: key);
@override
Widget build(BuildContext context, WidgetRef ref) {
// We are now watching our new Provider
// Our widget is no longer calculating whether we can go to the previous page.
final canGoToPreviousPage = ref.watch(canGoToPreviousPageProvider);
void goToPreviousPage() {
ref.read(pageIndexProvider.notifier).update((state) => state - 1);
}
return ElevatedButton(
onPressed: canGoToPreviousPage ? null : goToPreviousPage,
child: const Text('previous'),
);
}
}
通过这个小的重构,我们的PreviousButton Widget将不会在页面索引改变时重建,这都要归功于Provider的缓存作用。
从现在开始,当页面索引改变时,我们的canGoToPreviousPageProviderProvider将被重新计算。但是如果Provider暴露的值没有变化,那么PreviousButton将不会重建。
这个变化既提高了我们的按钮的性能,又有一个有趣的好处,就是把逻辑提取到我们的Widget之外。
我们再来看下StateProvider,它是一个公开了修改其状态的方法的Provider。它是StateNotifierProvider的简化版,旨在避免为非常简单的用例编写一个StateNotifier类。
StateProvider的存在主要是为了允许用户对简单的变量进行修改。一个StateProvider所维护的状态通常是下面几种。
而下面这些场景,就不适合使用StateProvider。
对于这些场景,你可以考虑使用StateNotifierProvider代替,并创建一个StateNotifier类。
虽然StateNotifierProvider的模板代码会多一些,但拥有一个自定义的StateNotifier类对于项目的长期可维护性至关重要--因为它将你的状态的业务逻辑集中在一个地方。
由此,我们可以了解,Riverpod最合适的场景,就是「单一状态值的管理」。例如,PageView的切换Index、ListView的切换Index,或者是CheckBox、dropdown的内容改变监听,这些是非常适合用StateProvider的。
官方给出了一个dropdown的例子,用来演示如何根据filter来修改列表的排序。
StateProvider在现实世界中的一个使用案例是管理简单表单组件的状态,如dropdown/text fields/checkboxes。特别是,我们将看到如何使用StateProvider来实现一个允许改变产品列表排序方式的dropdown。为了简单起见,我们将获得的产品列表将直接在应用程序中建立,其内容如下。
class Product {
Product({required this.name, required this.price});
final String name;
final double price;
}
final _products = [
Product(name: 'iPhone', price: 999),
Product(name: 'cookie', price: 2),
Product(name: 'ps5', price: 500),
];
final productsProvider = Provider<List<Product>>((ref) {
return _products;
});
在现实世界的应用中,这个列表通常是通过使用FutureProvider进行网络请求来获得的,然后,用户界面可以显示产品列表,就像下面这样。
Widget build(BuildContext context, WidgetRef ref) {
final products = ref.watch(productsProvider);
return Scaffold(
body: ListView.builder(
itemCount: products.length,
itemBuilder: (context, index) {
final product = products[index];
return ListTile(
title: Text(product.name),
subtitle: Text('${product.price} \$'),
);
},
),
);
}
由于这里是写死了products,所以使用Provider来作为数据Provider,是一个很好的选择。
现在我们已经完成了基础框架,我们可以添加一个dropdown,这将允许我们通过价格或名称来过滤产品。为此,我们将使用DropDownButton。
// An enum representing the filter type
enum ProductSortType {
name,
price,
}
Widget build(BuildContext context, WidgetRef ref) {
final products = ref.watch(productsProvider);
return Scaffold(
appBar: AppBar(
title: const Text('Products'),
actions: [
DropdownButton<ProductSortType>(
value: ProductSortType.price,
onChanged: (value) {},
items: const [
DropdownMenuItem(
value: ProductSortType.name,
child: Icon(Icons.sort_by_alpha),
),
DropdownMenuItem(
value: ProductSortType.price,
child: Icon(Icons.sort),
),
],
),
],
),
body: ListView.builder(
// ...
),
);
}
现在我们有了一个dropdown,让我们创建一个StateProvider并将dropdown的状态与我们的StateProvider同步。首先,让我们创建StateProvider。
final productSortTypeProvider = StateProvider<ProductSortType>(
// We return the default sort type, here name.
(ref) => ProductSortType.name,
);
然后我们可以通过下面这个方式,将StateProvider和dropdown联系起来。
DropdownButton<ProductSortType>(
// When the sort type changes, this will rebuild the dropdown
// to update the icon shown.
value: ref.watch(productSortTypeProvider),
// When the user interacts with the dropdown, we update the provider state.
onChanged: (value) =>
ref.read(productSortTypeProvider.notifier).state = value!,
items: [
// ...
],
),
有了这个,我们现在应该能够改变排序类型。不过,这对产品列表还没有影响。现在是最后一个部分了。更新我们的productsProvider来对产品列表进行排序。
实现这一点的一个关键部分是使用ref.watch,让我们的productProvider获取排序类型,并在排序类型改变时重新计算产品列表。实现的方法如下。
final productsProvider = Provider<List<Product>>((ref) {
final sortType = ref.watch(productSortTypeProvider);
switch (sortType) {
case ProductSortType.name:
return _products.sorted((a, b) => a.name.compareTo(b.name));
case ProductSortType.price:
return _products.sorted((a, b) => a.price.compareTo(b.price));
}
});
这就是全部代码,这一改变足以让用户界面在排序类型改变时自动重新对产品列表进行排序。
参考下面的这个场景,有时候,我们需要根据前一个状态值,来修改后续的状态值,例如Flutter Demo中的加数器。
final counterProvider = StateProvider<int>((ref) => 0);
class HomeView extends ConsumerWidget {
const HomeView({Key? key}): super(key: key);
@override
Widget build(BuildContext context, WidgetRef ref) {
return Scaffold(
floatingActionButton: FloatingActionButton(
onPressed: () {
// We're updating the state from the previous value, we ended-up reading
// the provider twice!
ref.read(counterProvider.notifier).state = ref.read(counterProvider.notifier).state + 1;
},
),
);
}
}
这种更新State的方法,我们可以使用update函数来简化,简化之后,代码如下。
ref.read(counterProvider.notifier).update((state) => state + 1);
所以,如果是对StateProvider的state进行赋值,那么直接使用下面的代码即可。
ref.read(counterProvider.notifier).state = xxxx
那么如果是根据前置状态的值来修改状态值,则可以使用update来简化。
StateNotifierProvider是一个用于监听和管理StateNotifier的Provider。StateNotifierProvider和StateNotifier是Riverpod推荐的解决方案,用于管理可能因用户交互而改变的状态。
它通常被用于下面这些场景。
作为一个使用例子,我们可以使用StateNotifierProvider来实现一个todo-list。这样做可以让我们暴露出诸如addTodo这样的方法,让UI在用户交互中修改todos列表。
// The state of our StateNotifier should be immutable.
// We could also use packages like Freezed to help with the implementation.
@immutable
class Todo {
const Todo({required this.id, required this.description, required this.completed});
// All properties should be `final` on our class.
final String id;
final String description;
final bool completed;
// Since Todo is immutable, we implement a method that allows cloning the
// Todo with slightly different content.
Todo copyWith({String? id, String? description, bool? completed}) {
return Todo(
id: id ?? this.id,
description: description ?? this.description,
completed: completed ?? this.completed,
);
}
}
// The StateNotifier class that will be passed to our StateNotifierProvider.
// This class should not expose state outside of its "state" property, which means
// no public getters/properties!
// The public methods on this class will be what allow the UI to modify the state.
class TodosNotifier extends StateNotifier<List<Todo>> {
// We initialize the list of todos to an empty list
TodosNotifier(): super([]);
// Let's allow the UI to add todos.
void addTodo(Todo todo) {
// Since our state is immutable, we are not allowed to do `state.add(todo)`.
// Instead, we should create a new list of todos which contains the previous
// items and the new one.
// Using Dart's spread operator here is helpful!
state = [...state, todo];
// No need to call "notifyListeners" or anything similar. Calling "state ="
// will automatically rebuild the UI when necessary.
}
// Let's allow removing todos
void removeTodo(String todoId) {
// Again, our state is immutable. So we're making a new list instead of
// changing the existing list.
state = [
for (final todo in state)
if (todo.id != todoId) todo,
];
}
// Let's mark a todo as completed
void toggle(String todoId) {
state = [
for (final todo in state)
// we're marking only the matching todo as completed
if (todo.id == todoId)
// Once more, since our state is immutable, we need to make a copy
// of the todo. We're using our `copyWith` method implemented before
// to help with that.
todo.copyWith(completed: !todo.completed)
else
// other todos are not modified
todo,
];
}
}
// Finally, we are using StateNotifierProvider to allow the UI to interact with
// our TodosNotifier class.
final todosProvider = StateNotifierProvider<TodosNotifier, List<Todo>>((ref) {
return TodosNotifier();
});
现在我们已经定义了一个StateNotifierProvider,我们可以用它来与用户界面中的todos列表进行交互。
class TodoListView extends ConsumerWidget {
const TodoListView({Key? key}): super(key: key);
@override
Widget build(BuildContext context, WidgetRef ref) {
// rebuild the widget when the todo list changes
List<Todo> todos = ref.watch(todosProvider);
// Let's render the todos in a scrollable list view
return ListView(
children: [
for (final todo in todos)
CheckboxListTile(
value: todo.completed,
// When tapping on the todo, change its completed status
onChanged: (value) => ref.read(todosProvider.notifier).toggle(todo.id),
title: Text(todo.description),
),
],
);
}
}
FutureProvider相当于Provider,但仅用于异步代码。
FutureProvider通常用于下面这些场景。
FutureProvider在与ref.watch结合时收获颇丰。这种组合允许在一些变量发生变化时自动重新获取一些数据,确保我们始终拥有最新的值。
FutureProvider不提供在用户交互后直接修改计算的方法。它被设计用来解决简单的用例。
对于更高级的场景,可以考虑使用StateNotifierProvider。
FutureProvider可以作为一种方便的方式来管理一个通过读取JSON文件创建的配置对象。
创建配置将用典型的async/await语法完成,但在Provider内部。使用Flutter的asset,这将是下面的代码。
final configProvider = FutureProvider<Configuration>((ref) async {
final content = json.decode(
await rootBundle.loadString('assets/configurations.json'),
) as Map<String, Object?>;
return Configuration.fromJson(content);
});
然后,用户界面可以像这样监听配置。
Widget build(BuildContext context, WidgetRef ref) {
AsyncValue<Configuration> config = ref.watch(configProvider);
return config.when(
loading: () => const CircularProgressIndicator(),
error: (err, stack) => Text('Error: $err'),
data: (config) {
return Text(config.host);
},
);
}
这将在Future完成后自动重建UI。同时,如果多个widget想要这些解析值,asset将只被解码一次。
正如你所看到的,监听Widget内的FutureProvider会返回一个AsyncValue - 它允许处理错误/加载状态。
StreamProvider类似于FutureProvider,但用于Stream而不是Future。
StreamProvider通常被用于下面这些场景。
由于Streams自然地暴露了一种监听更新的方式,有些人可能认为使用StreamProvider的价值很低。特别是,你可能认为Flutter的StreamBuilder也能很好地用于监听Stream,但这是一个错误。
使用StreamProvider而不是StreamBuilder有许多好处。
ChangeNotifierProvider是一个用来管理Flutter中的ChangeNotifier的Provider。
Riverpod不鼓励使用ChangeNotifierProvider,它的存在主要是为了下面这些场景。
更倾向于使用StateNotifierProvider来代替。
只有当你绝对确定你想要可变的状态时,才考虑使用ChangeNotifierProvider。
使用可变的状态而不是不可变的状态有时会更有效率。但缺点是,它可能更难维护,并可能破坏各种功能。
例如,如果你的状态是可变的,使用provider.select来优化Widget的重建可能就会失效,因为select会认为值没有变化。
因此,使用不可变的数据结构有时会更快。而且,针对你的用例进行基准测试很重要,以确保你通过使用ChangeNotifierProvider真正获得了性能。
作为一个使用例子,我们可以使用ChangeNotifierProvider来实现一个todo-list。这样做将允许我们公开诸如addTodo的方法,让UI在用户交互中修改todos列表。
class Todo {
Todo({
required this.id,
required this.description,
required this.completed,
});
String id;
String description;
bool completed;
}
class TodosNotifier extends ChangeNotifier {
final todos = <Todo>[];
// Let's allow the UI to add todos.
void addTodo(Todo todo) {
todos.add(todo);
notifyListeners();
}
// Let's allow removing todos
void removeTodo(String todoId) {
todos.remove(todos.firstWhere((element) => element.id == todoId));
notifyListeners();
}
// Let's mark a todo as completed
void toggle(String todoId) {
for (final todo in todos) {
if (todo.id == todoId) {
todo.completed = !todo.completed;
notifyListeners();
}
}
}
}
// Finally, we are using StateNotifierProvider to allow the UI to interact with
// our TodosNotifier class.
final todosProvider = ChangeNotifierProvider<TodosNotifier>((ref) {
return TodosNotifier();
});
现在我们已经定义了一个ChangeNotifierProvider,我们可以用它来与用户界面中的todos列表进行交互。
class TodoListView extends ConsumerWidget {
const TodoListView({Key? key}) : super(key: key);
@override
Widget build(BuildContext context, WidgetRef ref) {
// rebuild the widget when the todo list changes
List<Todo> todos = ref.watch(todosProvider).todos;
// Let's render the todos in a scrollable list view
return ListView(
children: [
for (final todo in todos)
CheckboxListTile(
value: todo.completed,
// When tapping on the todo, change its completed status
onChanged: (value) =>
ref.read(todosProvider.notifier).toggle(todo.id),
title: Text(todo.description),
),
],
);
}
}
这些不同类型的各种Provider,就是我们的军火库,我们需要根据不同的场景和它们的特性来选择不同的「武器」,通过文中给出的例子,相信大家能够很好的理解它们的作用了。
向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问
原文:https://xuyisheng.top/riverpod2/
Flutter是一款移动应用程序SDK,一份代码可以同时生成iOS和Android两个高性能、高保真的应用程序。Flutter目标是使开发人员能够交付在不同平台上都感觉自然流畅的高性能应用程序。我们兼容滚动行为、排版、图标等方面的差异。
关注flutter已经好久,因为没有发正式版,所以一直也不想过早的躺浑水,但是最近无意中看到几篇文章,再加上美团和咸鱼等app也一直在做灰度测试,所以上周开始看了一下官方文档,地址:https://flutter.io/docs/get-started/install,然后在此做一下总结。
Flutter默认是单线程任务处理的,如果不开启新的线程,任务默认在主线程中处理。和iOS应用很像,在Dart的线程中也存在事件循环和消息队列的概念,但在Dart中线程叫做isolate。
Flutter 1.5 的发布,同期也宣布发布 Flutter for Web 的 Preview 版本,正式开启了 Flutter 的全平台 UI 框架之路。早在年初发布的 Flutter 2019 Roadmap 中,就有提到,会在今年支持移动设备之外的平台,对 Web 的支持,算是完成了一个新的里程碑吧。
Flutter作为一个可移植的UI框架,已经支持现代Web应用开发了!我们很开心已经发布了SDK预览版,这样你可以在Web浏览器里直接运行你的Flutter UI代码。
Flutter 与原生之间的通信依赖灵活的消息传递方式:1,Flutter 部分通过平台通道将消息发送到其应用程序的所在的宿主环境(原生应用)。2,宿主环境通过监听平台通道,接收消息。
Flutter是借鉴React的开发思想实现的,在子组件的插槽上,React有this.props.children,Vue有<slot></slot>。当然Flutter也有类似的Widget,那就是Navigator,不过是以router的形式实现(像<router-view></router-view>)。
这两个技术在当下如何选择,我之前在公众号上的回复是:如果你已经处于一个比较满意的公司,并考虑长期发展,公司并未使用这两个技术,你可以专心钻研公司当下使用的,或者未来将要使用的,这些才能助你在公司步步高升。
本文对比的是 UIWebView、WKWebView、flutter_webview_plugin(在 iOS 中使用的是 WKWebView)的加载速度,内存使用情况。测试网页打开的速度,只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳
用来构建漂亮、定制化应用的跨平台的 UI 框架 Flutter 现在已经支持 Web 开发了。我们很高兴推出了一个预览版的 SDK 可以让开发者直接使用 Flutter UI 和业务逻辑代码构建 web 应用
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!