配景

在行使 Flutter 开拓进程中，我们碰着了营业代码耦合严峻，代码可维护性糟糕，如入泥泞。对付闲鱼这样的认真营业场景，我们必要一个同一的应用框架来挣脱当下的开拓逆境，而这也是 Flutter 规模空白的一块童贞地。

Fish Redux 是为办理上面题目上层应用框架，它是一个基于 Redux 数据打点的组装式 flutter 应用框架， 出格合用于构建中大型的伟大应用。

它的最大特点是设置式组装， 一方面将一个大的页面，对视图和数据层层拆解为相互独立的 Component|Adapter，上层认真组装，基层认真实现，另一方面将 Component|Adapter 拆分为 View，Reducer，Effect 等彼此独立的上下文无关函数。以是它会很是干净，易编写、易维护、易协作。

Fish Redux 的灵感首要来自于 Redux、React、Elm、Dva 这样的优越框架，而 Fish Redux 站在巨人的肩膀上，将齐集，分治，复用，断绝做的更进一步。

分层架构图

架构图，主体自底而上，分三层，每一层用来办理不通层面的题目和抵牾，下面依次来睁开。

Redux

• Redux 是来自前端社区的一个数据打点框架， 对 Native 开拓同窗来说也许会有一点生疏，我们做一个简朴的先容。

Redux 做什么的？

• Redux 是一个用来做可猜测易调试的数据打点的框架。全部对数据的增编削查等操纵都由 Redux 来齐集认真。

Redux 是怎么计划和实现的？

• Redux 是一个函数式的数据打点的框架。

传统 OOP 做数据打点，每每是界说一些 Bean，每一个 Bean 对外袒露一些 Public-API 用来操纵内部数据（充血模子）。
函数式的做法是更上一个抽象的纬度，对数据的界说是一些 Struct（血虚模子），而操纵数据的要领都同一到具有沟通函数署名 (T, Action) => T 的 Reducer 中。
FP:Struct（血虚模子） + Reducer = OOP:Bean（充血模子）
同时 Redux 加上了 FP 中常用的 Middleware（AOP） 模式和 Subscribe 机制，给框架带了极高的机动性和扩展性。
血虚模子、充血模子 参考：
[https://en.wikipedia.org/wiki/Plain_old_Java_object](https://en.wikipedia.org/wiki/Plain_old_Java_object)

Redux 的弱点

• Redux 焦点仅仅体谅数据打点，不体谅详细什么场景来行使它，这是它的利益同时也是它的弱点。
• 在我们现实行使 Redux 中面对两个详细题目
• Redux 的齐集和 Component 的分治之间的抵牾。
• Redux 的 Reducer 必要一层层手动组装，带来的繁琐性和易错性。

Fish Redux 的改善

Fish Redux 通过 Redux 做齐集化的可调查的数据打点。然不只于此，对付传统 Redux 在行使层面上的弱点，在面向端侧 flutter 页面纬度开拓的场景中，我们通过更好更高的抽象，做了改善。

一个组件必要界说一个数据（Struct）和一个 Reducer。同时组件之间存在着父依靠子的相关。通过这层依靠相关，

我们办理了【齐集】和【分治】之间的抵牾，同时对 Reducer 的手动层层 Combine 酿成由框架自动完成，大大简化了行使 Redux 的坚苦。

我们获得了抱负的齐集的结果和分治的代码。

对社区尺度的 follow

• State、Action、Reducer、Store、Middleware 以上观念和社区的 ReduxJS 是完全同等的。我们将原汁原味地保存全部的 Redux 的上风。
• 假如想对 Redux 有更近一步的领略，请参考 https://github.com/reduxjs/redux

Component

组件是对局部的展示和成果的封装。 基于 Redux 的原则，我们对成果细分为修改数据的成果(Reducer)和非修改数据的成果(副浸染 Effect)。

于是我们获得了，View、 Effect、Reducer 三部门，称之为组件的三要素，别离认真了组件的展示、非修改数据的举动、修改数据的举动。

这是一种面向当下，也面向将来的拆分。在面向当下的 Redux 看来，是数据打点和其他。在面向将来的 UI-Automation 看来是 UI 表达和其他。

UI 的表达对措施员而言即将进入黑盒期间，研发工程师们会把更多的精神放在非修改数据的举动、修改数据的举动上。

组件是对视图的分治，也是对数据的分治。通过逐层分治，我们将伟大的页面和数据切分为彼此独立的小模块。这将利于团队内的协作开拓。

关于 View

View 仅仅是一个函数署名: (T,Dispatch,ViewService) => Widget

它首要包括三方面的信息

• 视图是完全由数据驱动。
• 视图发生的变乱／回调，通过 Dispatch 发出“意图”，不做详细的实现。
• 必要用到的组件依靠等，通过 ViewService 尺度化挪用。

好比一个典范的切合 View 署名的函数![image.png](https://img.alicdn.com/tfs/TB1ymUNCgHqK1RjSZFPXXcwapXa-1198-1098.png) 

关于 Effect

Effect 是对非修改数据举动的尺度界说，它是一个函数署名: (Context, Action) => Object

它首要包括四方面的信息

• 吸取来自 View 的“意图”，也包罗对应的生命周期的回调，然后做出详细的执行。
• 它的处理赏罚也许是一个异步函数，数据也许在进程中被修改，以是我们不崇尚持稀有据，而通过上下文来获取最新数据。
• 它不修改数据， 假如修要，应该发一个 Action 到 Reducer 里行止理赏罚。
• 它的返回值仅限于 bool or Future， 对应支持同步函数和协程的处理赏罚流程。

好比：精采的协程的支持![image.png](https://img.alicdn.com/tfs/TB1bTgVChYaK1RjSZFnXXa80pXa-1256-944.png)

关于 Reducer

Reducer 是一个完全切合 Redux 类型的函数署名:(T,Action) => T

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!