Riverpod数据共享也是使用了InheritedWidget,在项目中,runapp外层要嵌套一个ProviderScope
void main() {
runApp(
ProviderScope(
child: MyApp(),
),
);
}
而ProviderScope是个StatefulWidget,在State build方法中,使用了UncontrolledProviderScope
image.png
UncontrolledProviderScope就是一个InheritedWidget
image.png
在我们使用
riverpod时候,获取的状态都保存在这个UncontrolledProviderScope中,具体是ProviderContainer对象当中,这里能够感受到的一个最大的优势就是不再依赖上下文,因为在任何地方获取的都是这个顶层的状态,像之前如果路由进行了跳转,路由1中的状态是没办法在路由2中获取到的,当然有方法去解决,但是会带来更多的代码和结构上的不合理.
image.png
riverpod提供的是顶层的InheritedWidget来管理所有的状态,很容易想到ProviderContainer中应该是有个Map来存储所有的状态,所有状态保存在顶层,下层组件想要使用状态,通过顶层的InheritedWidget获取ProviderContainer来使用
riverpod里边一个很特别的对象就是ref,在provider(指的riverpod中的状态)中有ref,在Consumer中也有一个ref,但是这两个ref是不一样的类型,这里也要说一下riverpod中的provider会有对应的element,所以可以简单的理解
provider 中的ref是providerElement
Consumer 中的ref是widgetElement,也就是说context可以被强制转化成ref
关于providerElement可以类比widget与element的关系,provider只是一个配置类,providerElement才是真实的状态管理类,只有providerElement创建才会产生真正的状态,所以在Riverpod中经常会看见类似这样的代码
final counterStateProvider = StateProvider<int>((ref)=>0)
StateProvider可能会被提前创建出来,但是真正的状态被创建,会在真正使用的时候
所以不必担心全局创建的provider
这里还是要做一个类比
InheritedElement与WidgetElement的关系与ProviderElement与ConsumerStatefulElement
InheritedElement中有_dependents,WidgetElement中有_dependencies
ProviderElement中有_dependents,ConsumerStatefulElement中有_dependencies
他们的含义是一样的_dependents代表哪些组件注册了刷新回调,_dependencies代表组件在哪些状态中注册了回调,有点绕,但是要理解
上边说了在顶层有一个保存所有状态的InheritedWidget,但是具体如何操作组件刷新的呢?
类比Provider状态管理,Riverpod也提供了两个方法read 和watch,含义是一样的read是用来读数据,watch不仅用来读也用来注册刷新回调
在ConsumerWidget中使用的ref我们上面说到是widget的element,我们执行ref.watch(countProvider)的时候
@override
Res watch<Res>(ProviderListenable<Res> target) {
_assertNotDisposed();
return _dependencies.putIfAbsent(target, () {
final oldDependency = _oldDependencies?.remove(target);
if (oldDependency != null) {
return oldDependency;
}
return _container.listen<Res>(
target,
(_, __) => markNeedsBuild(),
);
}).read() as Res;
}
_container就是顶层的ProviderContainer
_dependencies用来存放_container监听之后的ProviderSubscription,类比StreamSubscription,如果当前的element从element tree移除后,可以移除掉在_container中注册的刷新回调
@override
ProviderSubscription<State> listen<State>(
ProviderListenable<State> provider,
void Function(State? previous, State next) listener, {
bool fireImmediately = false,
void Function(Object error, StackTrace stackTrace)? onError,
}) {
return provider.addListener(
this,
listener,
fireImmediately: fireImmediately,
onError: onError,
onDependencyMayHaveChanged: null,
);
}
最终走到Provider的addListener 方法 node.readProviderElement(this)本质就是找到ProviderElement,这里其实也发现了ProviderElement与WidgetElement的一一对应的关系是_ProviderStateSubscription来管理的
_ProviderStateSubscription(
super.source, {
required this.listenedElement,
required this.listener,
required this.onError,
}) {
final dependents = listenedElement._dependents ??= [];
dependents.add(this);
}
构造函数可以看到_dependents添加了Subscription,也就是添加了组件的刷新回调,provider中的状态变化的时候可以遍历_dependents来刷新UI组件,实际也是这样做的
void _notifyListeners(
Result<StateT> newState,
Result<StateT>? previousStateResult, {
bool checkUpdateShouldNotify = true,
}) {
...
final listeners = _dependents?.toList(growable: false);
newState.map(
data: (newState) {
if (listeners != null) {
for (var i = 0; i < listeners.length; i++) {
final listener = listeners[i];
if (listener is _ProviderStateSubscription) {
Zone.current.runBinaryGuarded(
listener.listener,
previousState,
newState.state,
);
}
}
}
},
error: (newState) {
if (listeners != null) {
for (var i = 0; i < listeners.length; i++) {
final listener = listeners[i];
if (listener is _ProviderStateSubscription<StateT>) {
Zone.current.runBinaryGuarded(
listener.onError,
newState.error,
newState.stackTrace,
);
}
}
}
},
);
...
}
用StateProvider举例,在我们调用ref.read(countProvider.notifier).state++ 的时候会执行listenerEntry.listener(value)
set state(T value) {
assert(_debugIsMounted(), '');
final previousState = _state;
_state = value;
final errors = <Object>[];
final stackTraces = <StackTrace?>[];
for (final listenerEntry in _listeners) {
try {
listenerEntry.listener(value);
} catch (error, stackTrace) {
errors.add(error);
stackTraces.add(stackTrace);
if (onError != null) {
onError!(error, stackTrace);
} else {
Zone.current.handleUncaughtError(error, stackTrace);
}
}
}
if (errors.isNotEmpty) {
throw StateNotifierListenerError._(errors, stackTraces, this);
}
}
最终会调用到ProviderElement的setState,然后调用_notifyListeners
void setState(StateT newState) {
assert(
() {
_debugDidSetState = true;
return true;
}(),
'',
);
final previousResult = getState();
final result = _state = ResultData(newState);
if (_didBuild) {
_notifyListeners(result, previousResult);
}
}
而setState是在ProviderElement创建的时候就进行了注册
void create({required bool didChangeDependency}) {
final provider = this.provider as _StateProviderBase<T>;
final initialState = provider._create(this);
final controller = StateController(initialState);
_controllerNotifier.result = Result.data(controller);
_removeListener = controller.addListener(
fireImmediately: true,
(state) {
_stateNotifier.result = _controllerNotifier.result;
setState(state);
},
);
}
Riverpod实际做的对系统InheritedWidget的优化,让状态从组件数中抽离出来,
InheritedWidget时代,状态和组件本身就是一个东西(InheritedElement就是个特殊的WidgetElement),自己管理自己的状态,也就导致他严重依赖组件树的结构,如果两个处于不同分支下的状态想要相互调用是不可以的,但是Riverpod对他们进行了拆分,状态单独出来,并且通过索引保存在最顶层,这样既保持了状态和组件的1对1的关系,又实现了不同分支下的状态之间的相互调用
网友评论