Flutter Fish_Redux 3.0起航！ 序言 fish_redux 3.0.1 總結

作者：閒魚技術——啊丘

序言

fish_redux 2.0 FlowAdapter 功能優化，整體業務落地後，我們着手fish_redux新一輪的優化與架構演進。fish_redux 3.x 版本最終的目標保持fish_redux的“生命力”，在框架的易用性，可擴展，核心能力部分做到可持續發展。本文分爲三大主題，3.0版本首輪優化部分，架構的思考，後續fish_redux可持續輸出部分。

fish_redux 3.0.1

關於涉及應用開發領域，相信絕大多數同學都聽過或多或少了解MVC模型。MVC 是一個架構的描述，它有不少變種，如MVP， MVVM等，但本質上這些都屬於MVC的範疇。MVC的定義或解釋，不同的語言/領域/框架，又有不同的解釋。MVC模式（Model–View–Controller）是軟件工程中的一種軟件架構模式，把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。

當 視圖（View）從傳統的直接操作GUI對象 變爲聲明式UI/響應式UI。
會帶來兩個巨大的變化（MVVM變種）：
1）視圖（View）層，對開發者，抹去了GUI的中間狀態，複雜度進一步降低
2）MVC的之間的結構關係得到簡化和解耦，模型（Model）和控制器（Controller）不再依賴視圖（View）。

易用性和可維護性，往往是兩個層面的考慮：

• 易用性是對過往的歸納總結；
• 可維護性是對場景需求的進一步的抽象演繹；

那麼以fish_redux爲例：

• State定義 & Reducer函數 對應 Model層
• Effect函數對應Controller層
• View函數對應View層

fish_redux3.0目的是解決由於客戶端/前端應用層軟件墒快速上升, 提升軟件可維護性, 提高團隊協作效率。
客戶端/前端 應用層軟件複雜度快速上升,它的原因可能有這些:

1. 項目中缺少應用架構, 將完全無法應對需求迭代和人員迭代的變化。
2. 應用架構和現實需求的不匹配, 導致應用架構無法起到有效的隔離和複用的作用, 甚至成爲一種阻礙。
3. 開發者的認知和設計水平差異, 沒有達成團隊內有效的共識。

應用框架是應用架構的一種具體的代碼實現，以上幾點是fish_redux產生和演進的主要動機。
而當下fish_redux3.0的階段性目標:

1. 收到大家的反饋, 需要提升易用性。
2. 提高軟件的可維護性, 有傳承和延續性。
3. 試圖去整合覆蓋更多的閒魚內場景, 形成應用框架的統一編程範式。

fish_redux3.0.1版本第一步，提升fish_redux的易用性，可維護性。因此核心能力的概念精簡，整體實現代碼的瘦身是我們的首要目標。fish_redux2.0版本代碼量在3k+行，經過這次的精簡後整體代碼保持在1k行左右。接下來分三個緯度來介紹概念是如何精簡。

1.核心能力

fish_redux結合了Redux的狀態管理特點, 產生的基於狀態驅動&組裝式組件化&函數式&高性能的應用框架。

狀態驅動
在現代化的UI庫中, 都是響應式, 狀態驅動的。更進一步，在fish_redux中, 驅動UI是自動的。只要狀態變化，組件就會得到刷新。
**從分層視角看: **第一層狀態管理層, 負責了狀態的集中化管理, 向上提供了單一數據源下的組件化/狀態的讀寫和變更訂閱的能力. Middleware是設計用來做這一層的切面擴展能力.

組裝式組件化
在fish_redux中, 對組件和組件之間的關係, 做了全新的定義，目的是

1. 構建高度隔離的業務代碼.
2. 在隔離的基礎上, 提供了業務組件的複用單元.
3. 將組件與組件之間的依賴關係, 顯式聲明. 在衆多類型的詳情/發佈場景中, 提高了業務編排可讀性可維護性可擴展性.

函數式
將組件內的業務代碼, 通過抽象, 將業務代碼劃分爲View/Reducer/Effect三個角色.
每一角色負責單一職責. 每一單一職責都有每一確定的函數簽名來約束.

上訴核心能力梳理後，明確了各個功能層的核心類以及API。在狀態管理我們保留了基礎能力部分以及切面能力。
Redux：Store/Connector/DispatchBus/Action
切面能力：MiddleWare
我們做到了最小代碼兩情況下支持Redux框架能正常work，狀態驅動能力得到完美實現。

組件部分（Component）：View/Reducer/Effect/Context 組成。

優化前：

優化後：

顯而易見的是我們去除了redux_aop/redux_routes/redux_component_mixin等部分能力，這樣子做的目的是這一部分的能力非fish_redux的核心能力，是一些基於redux做的一些能力擴展，在fish_redux增加部分代碼徒增概念，使用者的理解成本會加大。
同時redux_middleware,redux_connector合併至redux之中，redux_adapter合併至redux_component之中。

2.層級收攏

fish_redux2.0實現Component引出了許多功能相近，差異度較低的抽象類,Component/Logic/AbstractLogic/AbstractComponent等。同時Adapter的實現在此基礎上更爲複雜，Adapter/AbstractAdapter/AbstractAdapterBuilder/Logic/AbstractLogic/AbstractComponent。如此層級下去閱讀實現，調試等成本是巨大的。因此我們對組件層的實現做到的了層級收攏，減少多餘的概念，保留了BasicComponent/Component/Adapter。

優化前：
abstract class Component<T> extends Logic<T> implements AbstractComponent<T> {
 .....
}

abstract class Logic<T> implements AbstractLogic<T> {
 ......
}

abstract class AbstractComponent<T> implements AbstractLogic<T> {
 .......
}

abstract class AbstractLogic<T> {
....
}

優化後：

class Component<T> extends BasicComponent<T> {
 ...
}
Class Adapter<T> extends BasicComponent<T> {
 ...
}
abstract class BasicComponent<T> {
 .....
}

同時我們對Context部分也做了相同的優化，上下文（Context）針對任何組件是相同的概念與實現。同時針對View接收Context保持了統一實現。原有Context部分：
ComponentContext/LogicContext/ContextSys/Context/ViewService
AdapterContext/LogicContext/ContextSys/Context/ViewService
多層級實現繼承在調試和概念理解也是有一定難度，對於這一部分的重構和減少層級部分我們也做出了變化。

fish_redux2.0:

class AdapterContext<T> extends LogicContext<T> {
}

class ComponentContext<T> extends LogicContext<T> {
}

abstract class LogicContext<T> extends ContextSys<T> with _ExtraMixin {
}

abstract class ContextSys<T> extends Context<T> implements ViewService {
}

abstract class Context<T> extends AutoDispose implements ExtraData {
}

abstract class ViewService implements ExtraData {
}

fish_redux3.0:

abstract class ComponentContext<T> {
}

class ComponentContextImp<T> extends ComponentContext<T> {
}

我們規範了Context只管理Component組件節點的上下文管理，對於虛擬組件，普通組件保持相同實現無差異化。Context目前負責Component的生命週期，消息發送，以及緩存等功能，同時保存了store已經BuildContext部分。對於代碼實現上一眼就能明白Context的能力實現，十分清晰。

3.擴展能力

擴展能力部分抽離，保持核心可擴展能力。View/Effect/Connector 等功能部件部分，我們做了一系列的擴展，方便使用等核心能力。考慮到對於這些功能爲非核心功能部分，不同使用者存在不同看法，同時統一app落地存在不同使用的方式。因此我們針對這些能力移動到後續fish_redux的擴展包中。
擴展能力部分的想法來自於Adapter的演進，Adpater的前身有許多功能性Adapter變種，DynamicFlowAdapter, StaticFlowAdapter等使用與不同列表的拉平功能。其核心能力歸結於FlowAdapter的Dependents的描述，試想針對這一類的變種是會源源不斷，不同場景實現也不相同。對於擴展包收攏該“實現”，基於fish_redux核心能力適應於不同場景的“變種功能”。
擴展包的想象力與趣味性還是很足的。針對View/Effect/Connector/Adapter等我們已經有很好的構思，擴展包也在持續輸出中。

總結

fish_redux2.0精簡版本至3.0部分，整體代碼量由3k+減少到目前的1k左右。在不斷的優化核心能力部分，相信更加簡便的實現和代碼優化會不斷的輸出。我們列舉了目前規劃的Action，在近期我們會不斷投入並且實現的部分。

1. 3.0 版本的release，和擴展能力包輸出並且release。同時也會對2.0版本適配DartSDK 2.x的適配。
2. 虛擬組件如何更優雅的實現，生命週期如何更合理化，虛擬組件如何更巧妙的嵌入。
3. Flutter側應用框架，對於不同業務類型的業務容器的支持。（目前支持ListView容器）

同時定製更長遠的計劃，不斷的像大家輸出更好的fish_redux。3.x的目標提升框架的“生命力”，是爲了讓更多的開發者參與到fish_redux的使用和建設中，不斷的完善改進，保持與Flutter的共同發展。所以在覈心實現層的代碼精簡，擴展能力層的輸出是讓開發者從運用層面，實現部分都能進來討論並且進入開發。只有這樣子可持續的發展進步才能讓更好的應用框架被開發者們使用，挖掘。我們也希望我們能在Github上做一些更多的討論，共同在Flutter側的Redux應用框架作出貢獻。fish_redux3.0-beta版本很快會與各位見面。