flutter泛型_Flutter架构组件（FAC）——Flutter解耦架构模型和跨组件状态管理

FAC&＃xff08;Flutter Architecture Components&＃xff09;

FAC Flutter 架构组件&＃xff08;Flutter Architecture Components&＃xff09; 致力于解决Flutter跨组件刷新和集中化状态管理、关注点分离、构建高性能Flutter页面&＃xff1b;

源码请查看&＃xff1a;Github

Feature

与Provider相比&＃xff1a;

• FAC提供了强大的解耦装置ViewModel&＃xff1b;
• 更为简洁的状态关联方式&＃xff1b;
• 以页面或APP纬度的集中化状态管理ViewModelStore&＃xff1b;
• 更高效的刷新机制&＃xff08;支持LiveState对状态隔离&＃xff0c;memo过滤参数列表&＃xff09;
• 在initState中可以触发状态更新&＃xff0c;比如加载数据&＃xff0c;初始化页面数据等

FAC架构组件模型

没错&＃xff0c;FAC看起来与AAC&＃xff08;Android Architecture Components&＃xff09;框架如出一辙&＃xff0c;我们构建了带有生命周期监听的可观察数据对象LiveState&＃xff0c;用于实现状态和UI控制器绑定&＃xff1b;并实现ViewModelStoreProxyWidget用来存储和卸载ViewModel对象——当然在业务开发中&＃xff0c;我们并不需要关注它的存在&＃xff0c;会在架构层合适的位置进行注入&＃xff1b;

这一切&＃xff0c;对熟悉Android原生AAC组件的开发者来说&＃xff0c;是一个福音&＃xff1b;因为相对大而笨重的Provider&＃xff0c;复杂的Redux框架来说&＃xff0c;对FAC的学习是零成本&＃xff01;

使用场景

• 组件状态共享&＃xff0c;组件间状态可被观察
• 跨组件通信/刷新
• 任意代码位置获取目标组件状态并刷新
• 某个组件需要改变全局状态
• 构建大型复杂业务及多页面嵌套场景

安装 FAC

修改 pubspec.yaml

使用

三步搞定企业级复杂业务场景、代码分层和状态管理&＃xff1a; - 1.定义ViewModel和Model数据类型

• 2.定义LiveState

• 3.UI和状态绑定

详细代码请查阅Github

数据流

架构设计背景

架构设计的初衷&＃xff0c;是为了解决Flutter在复杂的嵌套页面场景下&＃xff0c;能够有效的管理页面的状态和刷新效率&＃xff1b;对于简单的业务场景&＃xff0c;同样有友好的代码分层和状态管理能力&＃xff01;

以下是业务中采用FAC开发的Flutter页面&＃xff1a;

组件

1. LiveState组件

LiveState&＃xff1a;可被观察的数据组件&＃xff1b;称之为Live的原理&＃xff0c;是因为它可以感知Widget组件的生命周期&＃xff01;

LiveState 可用于构建可被观察的数据对象&＃xff0c;即构建model&＃xff1b;在数据发生变更时&＃xff0c;并且在生命周期合法的情况&＃xff0c;能够及时通知到观察者&＃xff1b;用于分发或转发数据对象&＃xff08;MediatorLiveState可以用作转发或合并数据源&＃xff09;&＃xff1b;

LiveState可以单独使用&＃xff0c;去构建跨组件刷新模型&＃xff1b; 但是我们更推荐将其放在 ViewModel 组件中&＃xff0c;这样可以将model对象转化成 ViewModel &＃xff0c;从而构建 UI 和 Model 分离的代码结构&＃xff01;

其他接口

LiveState提供其它相关接口&＃xff0c;用于响应式编程开发&＃xff1b;

• StateOwner 用于提供state的整体变更

• MediatorLiveState 用于合并多个LiveState数据源&＃xff0c;更利于构建响应式应用

• Transformations 用于LiveState数据源变化&＃xff0c;由于dart不支持反射&＃xff0c;可能并没有那么好用&＃xff0c;建议直接用 MediatorLiveState 替代

2. ViewModel组件

ViewModel&＃xff1a;分离数据和 UI&＃xff0c;专注于逻辑处理&＃xff0c;构建数据和UI的双向绑定&＃xff1b;

另外&＃xff0c;该类中提供appContext用于navigation等与element无关的调用&＃xff0c;该context来自于VMS&＃xff01;

1.生命周期安全

ViewModel 的声明周期与当前页面周期是一致的&＃xff0c;不需要担心内存泄漏或关注回收的工作&＃xff1b;

2.数据和UI解耦

直接使用 Provider&＃xff0c;需要手动构建 ViewModel 构建数据和 UI 的解耦模型&＃xff1b;而 ViewModel 组件为解决该问题应运而生&＃xff01; ViewModel 可以用来管理UI所需的相关数据&＃xff0c;承担UI和Model之间的交互和处理业务逻辑。 在页面的任何位置&＃xff0c;我们可以通过ViewModel.of(context)获取相应的 ViewModel 实例&＃xff0c;从而建立UI和Model的双向关联&＃xff01; ViewModel 可以胜任各种复杂的交互、业务逻辑、异步调用等&＃xff1b;我们所有的修改都基于model&＃xff0c;model 会自动关联注册的UI对象&＃xff08;Flutter Widget&＃xff09;&＃xff0c;从而构建一个单一数据源的模型; 因为组件的刷新是通过Model自动关联的&＃xff08;而不是调用 State 中的 setState()方法&＃xff09;&＃xff0c;我们更期望通过仅使用StatelessWidget去构建应用&＃xff01;

3.构建跨组件通信接口

ViewModel用来提供自定义组件刷新接口 比如一个 AppBar需要提供title改变的接口&＃xff0c;或 AppBar 的右侧Action中提供一个购物车数量指示。典型的跨组件刷新问题&＃xff0c;可以通过 ViewModel 向往提供接口&＃xff0c;开发者可以按需调用&＃xff01;

3. ViewModelStoreProxyWidget 组件

类似Redux中Store但是 ViewModelStoreProxyWidget 中共享的数据是当前页面相关的&＃xff1b;开发者往往不需要关注它的存在&＃xff0c;因为我们会通过框架在合适的位置注入。

_ViewModelStore 数据存储组件

类似Android中 lifecycle-viewmodel 组件包里的 ViewModelStore 组件&＃xff0c;ViewModelStoreProxyWidget 作为页面顶级Widget&＃xff0c;通过 InheritedWidget 共享页面的数据&＃xff01;当然&＃xff0c;它的存储方式和原生端 VMS 如出一辙&＃xff0c;采用Map()对ViewModel进行存储&＃xff1b;另外&＃xff0c;我们为了适应复杂的大型应用场景&＃xff0c;增加了final _factoriesByName &＃61; Map();的存储方式&＃xff0c;可以存储多个同名的 ViewModel&＃xff0c;使得单页面中的同组件类型接口问题得以解决!

设计原理

代理拦截与代理穿透

• 代理拦截

我们在任何位置可以轻松获取数据源并刷新UI的便利很大程度来源于代理拦截机制。如下&＃xff0c;ViewModel.of(context).model

所谓的代理机制&＃xff0c;原理很简单&＃xff0c;我们会通过Provider在合适位置注册VMS进行节点拦截&＃xff0c;因为inheritWidget会在最近位置通过泛型获取数据&＃xff0c;从而达到拦截的目的。 收益&＃xff1a; - 防止外层页面和当前子页面数据混用 - 在任何位置可以获取数据并刷新UI

• 代理穿透

供代理拦截机制后&＃xff0c;我们如何获取外层组件数据呢&＃xff1f; ViewModel提供了一种代理穿透的方式获取更外层数据。

代理拦截和代理穿透模式如下

代理穿透演示

共享Stroe

页面通过 instanceName 参数&＃xff0c;可以在一个VMS下面共享多个同类型ViewModel&＃xff1b;从而在一个页面下面&＃xff0c;可以嵌套多个同类型组件&＃xff0c;并调用不同组件的方法&＃xff1b;

拓展

自定义组件接口

自定义组件如何对外提供组件刷新接口&＃xff1f;

直接使用Provider

Provider的方式是通过在上层节点上挂载Provider通过ChangeNotifier构建的Model刷新 Provider 实例刷新Consumer下的子组件。这个过程对于我而言&＃xff0c;异常的漫长&＃xff0c;且过于耦合&＃xff1b;不能提供一个对外跨组件刷新的接口。

使用FAC

有没有什么方式能通过&＃xff0c;提供自定义组件的同时&＃xff0c;提供组件的对外刷新接口&＃xff0c;且这个组件刷新接口可以在代码的任何位置被调用&＃xff1f;比如 AppBar 提供标题修改的接口&＃xff0c;购物车提供商品数量变化的接口&＃xff1b;

• LoadingPage实现
  LoadingPage是页面状态管理组件&＃xff0c;有页面加载、错误、空数据、显示等状态&＃xff1b;

由于使用FAC时&＃xff0c;可以在页面任意位置获取ViewModel的实例&＃xff0c;我们可以在开发自定义Widget LoadingPage的时候提供一个VM接口&＃xff1b;外部可以使用该接口进行刷新&＃xff1a;

请查阅关于LoadingPage的组件实现Github

• AppBar刷新和购物车接口

参考

• 应用架构指南
• LiveData beyond the ViewModel — Reactive patterns using Transformations and MediatorLiveData
• Understanding LiveData made simple