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

背景

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

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

進化後的UI2CODE?

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

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

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

核心設計思路

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

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

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

消息機制

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

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

自身:Card發出的消息將由自身定義的Reaction處理

兄弟間:Reaction內可選擇轉發,能夠指定轉發的對象爲另一張Card

​​​​​​​

父對子:可於Page內指定發送的Card

​​​​​​​

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

總結進化的UI2CODE

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

將來展望

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

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


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

相關文章
相關標籤/搜索