在学习怎么使用AppRoute前,先了解下这几个问题,确定这是否是你需要的
-
为什么Redux.js和Vuex是全局Store?
前端的单页面应用越来越复杂,一个model变化会引起另外一个model变化,又可能引起视图变化。Redux的三大原则,使state的变化可预测成为可能。其中第一条就是单一数据源,这体现了集中思想。应用维护一颗状态树,而数据变化驱动视图重新刷新。单一的状态树更方便数据的管理,由于生命周期和App一致,组件间数据也更方便传递分享(如登录信息)。
-
为什么Fish Redux不是这样的?
Fish Redux一开始只支持Page级别Stroe是业务的客观诉求。Flutter作为一个新技术栈要用在一个上亿用户的闲鱼App中,需要风险控制和隔离,只能先改写一些页面,验证改进迭代再逐步替换。
-
我是否需要使用AppRoute?
如果你的诉求和闲鱼一样,那选择的是高难度路线,需要在集中和分治间做长久斗争。建议使用HybridRoute能省点时间,也方便后续改造。不然,那就用AppRoute吧,充分享受Flutter和Redux带来的优越性。
设计思想
作者添加了Route这一层,它的核心作用是产生一个Page,对应不同场景,实现了三个具体的XXXRoute
/// Route 抽象类,只提供返回一个page的能力abstract class AbstractRoutes { Widget buildPage(String path, dynamic arguments);}/// AppRoutes实现多page公用一个store,适合全新App使用class AppRoutesimplements AbstractRoutes { final Map > pages; final PageStore _store; ...}/// 一个page,一个store,适合部分页面改写flutter的App使用,如现在的闲鱼 class PageRoutes implements AbstractRoutes { final Map > pages; ...}/// 混合Routes,可以同时使用AppRoutes和PageRoutes,适合都要的App,如未来一段时间的闲鱼class HybridRoutes implements AbstractRoutes { final List routes; ...} 复制代码
使用方式
-
定义一个AppRoute
/// app_route.dart/// 因为是全局的,这里用单例,也比较方便调用class AppRoute { static AbstractRoutes _global; static AbstractRoutes get global { if (_global == null) { _global = AppRoutes(preloadedState: AppState.initialState(), pages: { // 这里有两种写法,效果是一样的,带操作符的写法比较生动,也简短些。 // RoutePath.todoList: TodoListPage().asDependent(TodoListConn()), RoutePath.todoList: TodoListConn() + TodoListPage(), RoutePath.todoDetail: TodoDetailConn() + TodoDetailPage(), }); } return _global; }}/// 减少魔法字段,这些常量放在constant里也可以,放在这里只是方便。class RoutePath { static const String todoList = 'todo_list'; static const String todoDetail = 'todo_detail';}复制代码
-
定义一个AppState,用来作为状态树的根节点
/// screens/todo_list/state.dartclass AppState implements Cloneable
{ TodoListState todoListState; TodoDetailState todoDetailState; AppState(this.todoListState, this.todoDetailState); @override AppState clone() { return AppState(todoListState, todoDetailState); } AppState.initialState() : todoListState = initState(null), todoDetailState = TodoDetailState();}复制代码 -
定义Connect,描述subState和父State之间的转化关系
/// screens/todo_list/state.dart/// get定义从大state取小state,set定义小state怎么改变大stateclass TodoListConn extends ConnOp
{ @override TodoListState get(AppState state) => state.todoListState; @override void set(AppState state, TodoListState subState) => state.todoListState = subState;}复制代码 -
替换原来Page产生的方式
/// main.darthome: AppRoute.global.buildPage(RoutePath.todoList, null),复制代码
-
额外处理(有数据跳转的Page)
/// screens/todo_detail/reducer.dart/// 页面跳转可能会有数据传递,比如list到detail页面,需要传递id,/// 这是很常见的,那数据什么时候传递?自然是page生成的时候,可以看到[AbstractRoutes]/// 的buildPage接受一个arguments参数,dynamic你可以传任意结构数据,推荐传Map,原生json样式/// 如果arguments不为null,Route会帮我们发一个route的Action,/// 所以我们需要在对应的Reducer里处理一下Reducer
buildReducer() { return asReducer (
对比体验Flutter Redux
一直以来Fish Redux和Flutter Redux的最佳实践并不同,一个是Page级别的状态管理,一个是App级别状态管理,所以算是错位竞品。在Fish Redux加入Route后,它也算完全体了,这两个都用过后我简单对比下:
-
方便度
Flutter Redux调用简单,想要深入理解API含义,会难一些。Fish Redux概念多,感觉是把二维数组flat了,大堆的定义和概念,可能会劝退小部份没耐心的同学。然而框架意图是清晰的,而且代码也有精心设计的痕迹。这点对我而言平分秋色。
-
文档例子
Flutter Redux优胜,文档和例子都比刚开源的Fish Redux多很多,Fish Redux文档不多但都有中文版哦
-
问题响应
Fish Redux优胜,Github上Issue基本能在12小时内得到作者或热心网友的回复和解答。而Flutter Redux的作者维护了很多个库,精力有限,所以Issue处理速度可以说是拖拖拉拉了
-
完备度
功能上都是完备的,形式上Flutter Redux需要依赖两个库,Fish Redux没有任何其他三方依赖会好一点点
-
性能
其实状态管理的初衷并不会很在意性能,毕竟它只是个状态管理啊,管理都需要额外成本的。但是fish redux确实关注了并对于大列表场景做了比较突出的优化,性能提升刚刚的。
总结:Fish Redux完全可以成为Flutter状态管理的备选方案了,而且它还正以肉眼可见的速度在成长。
后续
对比过后觉得Fish Redux不错,想推销给长官
我:报告老板,ali的Fish Redux老NB了,我们项目要不用这个吧?
老板:哪NB了?
我:巴拉巴拉~
老板:哪些大厂在用了
我:额,貌似就ali
老板:单元测试覆盖多少?
我:快50%吧
老板:性能提升多少,有benchmark吗?
我:。。。
抱歉,以上是我脑补的,但以我老板的专业度,这些问题必问。。。
本文源码地址:https://github.com/hyjfine/flutter_redux_sample/tree/fish-redux-route
(完)
, 本文版权属于再惠研发团队,欢迎转载,转载请保留出处。