点击上方蓝字关注我,知识会给你力量
随着每一个新版本的发布,Riverpod 及其生态系统都在不断完善:
核心软件包为反应式缓存和数据绑定提供了强大的应用程序接口
Riverpod Generator 软件包简化了学习曲线并带来了显著的可用性改进(我在这里已经介绍过了)
Riverpod Snippets扩展帮助我们轻松创建提供者和消费者
新的 Riverpod Lint 添加了许多有用的Lint和重构选项,让编写 Flutter 应用程序变得轻而易举。
等等...
还不止这些。
使用 Riverpod 进行现代开发是一件乐事,因为你只需编写少量代码,就能编写搜索和分页等复杂功能(让工具来指导你)。
在本文中,我将向你展示我是如何使用所有最新的好东西,包括代码生成、代码片段、重构选项和新的Riverpod lints,将我的时间跟踪应用程序重构为新的@riverpod语法的。
❝本文将展示 Riverpod Generator、Riverpod Lint 和 Riverpod Snippets extension 如何完美结合使用,但并不打算将其作为完整的资源。
添加所有必需的packages
由于我们将使用 Riverpod Generator 和 Riverpod Lint,因此需要在 pubspec.yaml 文件中添加一些packages:
dependencies:
# the main riverpod package for Flutter apps
flutter_riverpod:
# the annotation package containing @riverpod
riverpod_annotation:
dev_dependencies:
# a tool for running code generators
build_runner:
# the code generator
riverpod_generator:
# riverpod_lint makes it easier to work with Riverpod
riverpod_lint:
# import custom_lint too as riverpod_lint depends on it
custom_lint:
我们还需要在 analysis_options.yaml 中启用 custom_lint 插件:
analyzer:
plugins:
- custom_lint
接下来,我们需要在观察模式下启动 build_runner:
dart run build_runner watch -d
-d 标志是可选的,与 --delete-conflicting-outputs 相同。顾名思义,它可以确保我们覆盖先前构建中的任何冲突输出(这通常是我们想要的)。
这将监控项目中的所有 Dart 文件,并在我们进行修改时自动更新生成的代码。
现在设置已经完成,让我们来看一些代码。👇
使用Riverpod Generator 和 Riverpod Lint重构示例
假设我们有一个 AuthRepository 类,用来封装 FirebaseAuth 类:
// firebase_auth_repository.dart
import 'package:firebase_auth/firebase_auth.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
class AuthRepository {
AuthRepository(this._auth);
final FirebaseAuth _auth;
Stream<User?> authStateChanges() => _auth.authStateChanges();
}
假设我们也有这些providers:
// Make the [FirebaseAuth] instance accessible as a provider
final firebaseAuthProvider = Provider<FirebaseAuth>((ref) {
return FirebaseAuth.instance;
});
// Make the [AuthRepository] instance accessible as a provider
final authRepositoryProvider = Provider<AuthRepository>((ref) {
return AuthRepository(ref.watch(firebaseAuthProvider));
});
// A [StreamProvider] for the [authStateChanges] stream
final authStateChangesProvider = StreamProvider.autoDispose<User?>((ref) {
return ref.watch(authRepositoryProvider).authStateChanges();
});
如何将providers转换为新的 Riverpod 生成器语法?
添加prat文件
正如我们在关于 Riverpod Generator 的文章中所看到的,第一步是添加一个.part文件。
通过使用 Flutter Riverpod Snippets 扩展,我们只需键入几个字符即可:
扩展会自动使用正确的文件名完成这一操作:
part 'firebase_auth_repository.g.dart';
转换一个简单的provider
接下来,让我们看看如何转换这个provider:
final firebaseAuthProvider = Provider<FirebaseAuth>((ref) {
return FirebaseAuth.instance;
});
同样,我们可以从输入 riverpod 开始,得到一个选项列表:
在决定选择哪个选项时,我们可以问自己
这个provider会返回一个对象、一个 Future、一个流还是一个 Notifier?
当不再被监听时,它应该自行处置,还是继续存活?
由于 FirebaseAuth 是一个在整个应用生命周期中都保持存活的单例,因此我们可以选择 riverpodKeepAlive 选项,最后得到如下结果:
下一步是在空白处添加
返回类型
函数名称
添加其它附加参数(本例中没有)
provider主体功能
这就是我们的最终结果:
@Riverpod(keepAlive: true)
FirebaseAuth firebaseAuth(Ref ref) { // Stateless providers must receive a ref matching the provider name as their first positional parameter.dart(stateless_ref)
return FirebaseAuth.instance;
}
这段代码几乎是正确的。但 Riverpod Lint 提醒我们必须使用正确的类型,因为生成器会为每个provider创建特定的 Ref 类型。
事实上,函数名称(firebaseAuth)与生成的 Ref 类型和provider名称之间有严格的关系:
firebaseAuth() → FirebaseAuthRef 和 firebaseAuthProvider
因此,让我们再次使用 “快速修复”:
然后就好了!Lint警告就消失了:
@Riverpod(keepAlive: true)
FirebaseAuth firebaseAuth(FirebaseAuthRef ref) {
return FirebaseAuth.instance;
}
只要 build_runner 仍在观察模式下运行,就会生成一个 firebaseAuthProvider(在 part 文件中),并可在我们的代码中使用。
重构其余provider
接下来,我们还需要重构其余两个provider:
// Make the [AuthRepository] instance accessible as a provider
final authRepositoryProvider = Provider<AuthRepository>((ref) {
return AuthRepository(ref.watch(firebaseAuthProvider));
});
// A [StreamProvider] for the [authStateChanges] stream
final authStateChangesProvider = StreamProvider<User?>((ref) {
return ref.watch(authRepositoryProvider).authStateChanges();
});
在 Riverpod Snippets 和 Riverpod Lint 的帮助下,这很容易做到:
@Riverpod(keepAlive: true)
AuthRepository authRepository(AuthRepositoryRef ref) {
return AuthRepository(ref.watch(firebaseAuthProvider));
}
@riverpod
Stream<User?> authStateChanges(AuthStateChangesRef ref) {
return ref.watch(authRepositoryProvider).authStateChanges();
}
请注意,我选择在 firebaseAuthProvider 和 authRepositoryProvider 中使用 keepAlive,但没有在 authStateChangesProvider 中使用 keepAlive。这是有道理的,因为前两个provider包含长期依赖关系,而第三个provider可能需要也可能不需要始终监听。
示例 生成 AsyncNotifier
除了为objects, futures, 和 streams创建provider外,我们还想为 Notifier 和 AsyncNotifier 等类生成provider。
例如,下面是我的项目中的 AsyncNotifier 子类:
class EditJobScreenController extends AutoDisposeAsyncNotifier<void> {
@override
FutureOr<void> build() {
// omitted
}
// some methods
}
我本可以手工转换。
不过,Riverpod Snippets 提供了方便的 riverpodAsyncClass 和 riverpodClass 选项,再次帮助了我们:
选择上述选项后,我们就得到了这样的代码:
然后,我们就可以填补空白了:
@riverpod
class EditJobScreenController extends _$EditJobScreenController {
@override
FutureOr<void> build() {
// omitted
}
}
Riverpod Lint 还能做什么?
上面的示例展示了如何将现有provider或notifiers转换为新语法。
但你还可以用Riverpod Lint做更多事情,包括:
从StatelessWidget转换为ConsumerWidget或ConsumerStatefulWidget
在functional 和 class variants 之间转换
请再次查看官方文档,了解完整的选项列表。
总结
在 Riverpod 的早期,选择正确的provider并使用正确的语法很困难(尤其是在处理带有参数的复杂provider时)。
但正如我们所见,Riverpod Generator 和 Riverpod Lint 让我们的工作变得简单多了。
如今,将任何provider转换为新的 @riverpod 语法只需以下步骤:
使用 Riverpod Snippets 扩展添加part文件
选择正确的provider(同样使用 Riverpod Snippets)
填写空格(返回类型、函数名和参数)
选择正确的 Ref 类型(Riverpod Lint 简化了这项工作)
完成这些后,我们就可以保存文件,然后 build_runner 就会处理剩下的工作。
本文翻译自:https://codewithandrea.com/articles/flutter-riverpod-lint/#adding-all-the-required-packages
向大家推荐下我的网站 https://www.yuque.com/xuyisheng 点击原文一键直达
专注 Android-Kotlin-Flutter 欢迎大家访问
往期推荐
本文原创公众号:群英传,授权转载请联系微信(Tomcat_xu),授权后,请在原创发表24小时后转载。
< END >
作者:徐宜生
更文不易,点个“三连”支持一下👇