UI2CODE再進化！結合Redux的框架升級！

摘要： 自從有了ui2code，媽媽不再用擔憂我加班

背景

UI2CODE的目標是經過分析視覺稿獲得對應的代碼，讓AI提升開發效率。然而過去靜態化頁面的產出，不能獲得業務場景的需求。針對於此，咱們以UI2CODE自動化開發爲基底，結合Redux的消息機制，將自動化生成的維度提高到頁面的處理。

透過框架，可自動化生成頁面代碼，而且具備數據驅動展現、消息派送等動態性能力。指望在複雜的業務場景下，簡化開發的工做。而且在使用一致化的架構下，避免將來業務代碼耦合嚴重，使代碼分工明確，容易修改維護。

進化後的UI2CODE？

開發者能夠透過Intellij Plugin分析視覺稿後會生成對應的視圖代碼，以及和此頁面框架結合的能力。

在總體開發的定位上咱們的野心是，提供一套可擴充的頁面消息框架，而且自動生成大部分的UI代碼。目標帶來如下的好處：

1. 快速建構新應用，框架將完成大部分的事，業務開發同窗只要專一於業務代碼
2. 讓開發人員的進入門檻下降，在咱們落地的經驗中，後端同窗只要有基本的概念，無需花費太多經歷，可直接上手幫忙寫代碼
3. 讓頁面的架構統一化，讓頁面的開發有統一的規則，也方便後續的維護
4. 提供通用的組件庫，可重複利用

核心設計思路

咱們在設計上主要參考於MVP、CLEAN、VIPER以及FISH_REDUX等框架。目的在實踐高聚合低耦合的前提下，分拆爲視圖組裝層、視圖展現層、數據層、事件交互層。層層分離職責，不互相干擾，又可互相通信。

分層拆開的好處爲容易維護，而且能夠單元測試"業務展現"以及"業務邏輯"，框架上清晰，容易有一個統一的遵循規則，達到簡單編寫重複可利用。

UI2CODE頁面框架的設計概念爲，主要分爲Page、Card、Reaction三大元素。在上層的Page負責組裝頁面，制定頁面的風格。Card則爲可重複利用的視圖展現元素。Reaction則爲事件反應的監聽。

在整個頁面框架上，能夠透過UI2CODE Plugin分析自動化生成業務UI，產生出Page、Card、Card(DataModel)。僅需修改Card上額外的業務展現，以及撰寫Reaction中的業務邏輯。

具體實現架構

在介紹框架組件前，先理解UI2CODE的基本組成頁面目錄以下：

以Page爲單位，頁面本體demo_page爲其餘頁面路由調用的起點，透過設置Config.dart決定內部含的卡片列表以及事件處理列表，組合出Card以及Reaction的關聯。

其詳細的架構關係以下：

Page

Page爲框架基礎的單位，爲單一頁面，負責決定視圖的組裝以及頁面的樣式(Template)。

在Page以內可包含若干的Card以及Reaction，分別爲視圖的展現以及視圖的事件處理。能夠很清晰地將業務場景作分割成小模塊，不互相影響。

Abstract class PageStatelessWidget extends StatelessWidget

implements Lifecycle

• 可由UI2CODE Plugin自動化產生

• 框架統一分發管理頁面生命週期Lifecycle
• 透過設定Template指定頁面要呈現的樣版，或者修改如背景等屬性
• 透過設定Config指定這個頁面含有的Cards和Reactions
• 透過設定PageState可添加額外的數據

Page Template

Template樣板爲頁面的抽象化，在總體頁面上分爲多個樣板可選擇。而且支持設置AppBar(非必選)、Header(非必選)、Body、Stack(非必選)等子樣板。

樣板可比喻爲頁面的容器，目前支持如下樣板，而且可擴充：

1. PageTemplate，通用頁面容器，並支持NestedScrollView的Silver Header滾動(若須要)
2. PageBottomNavigatorTemplate，含有底部導航的容器，如首頁
3. PageSwitchTabTemplate，含有分頁Tab功能的容器

各個子樣板也有相對應的Template可選擇，如在Body內的樣板功能爲決定內部Cards排列的方式。舉例來講，BodyListViewTemplate則是列表展現。

使用Template最大的好處爲減小開發工做，可直接使用封裝後的接口。而且頁面內的全部樣板將共用消息機制，能夠互相傳遞消息，如Body內部的卡片很容易發送消息給AppBar等。這是框架上的有力之處。

Page Config

Config決定頁面的組裝，包含了元件有哪些，以及事件處理反射的類綁定。

Extends PageConfig

• 可由UI2CODE Plugin自動化產生

• 透過設定cards註冊這個頁面所載入的卡片
• 透過設定actions註冊這個頁面所響應的類，支持卡片事件以及頁面事件
• 支持額外設置AppBar、Header、Stack等組件(非必須)

如何綁定，舉例來講：

void actionConfig(List< List < Function>> actions) {
//卡片Card8575, 響應事件的類爲Card8575Reaction
actions.add(< Function>[() => Card8575, () => new Card8575Reaction()]);
}

Card

Card表明基本的視圖展現，業務UI，其中包含了View widget以及DataModel數據。框架內會將二者Data binding起來，由數據來驅動最終展現的呈現。達到如MVP中View和ViewModel的隔離效果。

Abstract class BaseCard<T extends DataModel> extends StatefulWidget

• 可由UI2CODE Plugin分析視覺稿產生

• 透過BaseCard<T extends DataModel>的標準化，指定數據DataModel綁定
• Card能夠發出事件，不直接操控數據，而讓接收者響應

Reaction

Reaction表明著事件發生的響應，能夠選擇是否處理事件。若選擇處理，可同步或異步修改對應的數據DataModel。

Abstract class CardReaction<S, D extends DataModel>

• init()爲初始化事件，自動發出，可進行一些初始動做

• RegisterReactions()註冊感興趣的事件handler
• 可於handler上加上aysnc，指定爲異步處理
• Reaction內依據事件修改DataModel，只要關注事件改變後的數據，自己不持有數據，視圖將會自動刷新

舉例來講：

//如發送rAssignPrice的事件
doAction(Card6736Event.rAssignPrice);

//接收rAssignPrice的事件, 並對數據作處理
@override
Map

 Card6736Event.rAssignPrice: (PageItemBean state, CardAction action, Card6736DataModel data) {
   //修改數據欄位
   data.userName = "123";
 },
}

結合Redux

在頁面框架的背後，咱們採用了Redux來進行封裝。

Redux是一套的數據管理的框架。全部的數據的儲存於Store的State內。當事件發生時，會發生不一樣的Action，根據事件響應不一樣的Reducer去改變State。若通過響應後State有所變化，則綁定的視圖會視須要作對應的刷新。

詳細Redux：能夠參考 https://github.com/reduxjs/redux

咱們應用了Redux中等State、Action、Reducer、Store、Middleware的概念，將頁面賦予生命狀態，而頁面內的組件間可支持消息機制。Redux對剛入門的同窗仍是有必定的門檻所在，但在本框架的封裝下，基本上感受不到Redux的存在。

消息機制

在UI2CODE消息框架下，頁面內的各個組件以及容器均可以彈性的進行消息傳遞。能夠由Page、Card、Reaction等處任意的發送消息，達到(自身、兄弟間、子對父、父對子)的通知。

各類消息傳遞的路徑說明以下：

1. 自身：Card發出的消息將由自身定義的Reaction處理

1. 兄弟間：Reaction內可選擇轉發，能夠指定轉發的對象爲另一張Card

1. 父對子：可於Page內指定發送的Card

1. 子對父: 若發出的消息在Card內無人處理，則會冒泡到Page層級處理

總結進化的UI2CODE

• 框架簡單，只需瞭解框架基本的元素，不須要會Redux就能夠達到數據管理的效果。目前閒魚內部的新應用落地，全部的頁面均透過框架的機制來達到消息傳遞。而其中1/3頁面UI爲透過自動化生成，減小了約一半的總體開發時間。
• 由於組件的分層解耦，維護時能夠清晰看到頁面的組成及覆用代碼。而且在修改組件時，不影響到其餘組件的做用。
• 事件能夠在頁面框架下自由的傳遞，達到高聚合的效果，而且響應支持同步和異步的流程。開發者只須要關心數據處理，視圖的刷新將會由框架處理。

將來展望

透過整合UI2CODE Plugin，使用插件可透過AI自動分析產生Page、Config、Card等。開發者能夠在自動化的基礎上再進行修改，大大減小從無到有的開發時間。咱們指望開發者只須要專一的修改業務展現以及業務邏輯，不須要對頁面設置作過多的處理。

透過與業務上的合做，咱們得到了不少實際上的想法，以及對於不一樣業務場景的適應。在這些經驗上不斷地優化框架，讓框架更解耦，支持能力更多。將來咱們但願是不僅閒魚內部的應用，也擴展給更多的應用！

---

本文做者：閒魚技術 - 餘晏

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。