在平常業務開發中,我發現不少人會習慣於,直接拿UI庫+業務代碼的形式,去作平常開發,而且鍥而不捨。這不是錯誤,只是在求快的前提下,作的妥協而已。固然對於項目初期,我舉雙手贊同這種模式。可是當業務隨着時間的推移,產品模式的固定,交互模式的固定,那麼這種形式勢必須要拋棄。"模式庫"就要須要上線了。react
模式庫的含義是,根據現有業務,根據既定交互,結合UI庫+業務的組合形式,而且以純數據組織,實現業務開發。這樣作的優點在於,提升開發效率,將UI展示實行一致化,提升可維護性。下面,我以ant-design爲UI庫,結合一些常見業務進行解釋。json
例子:codesandbox.io/embed/magic…數據結構
這是一個常見的搜索功能,咱們會涉及到,Input, Checkbox, DatePicker, TimePicker, Row, Col, Button, Typography組件。首先這種業務需求是能夠固化的,無論是在前臺、後臺都是如此,並無太多套路可言。spa
共性:一組表單,點擊提交將表單的name和value返回出來,點擊重置將默認值賦值給表單。設計
差別性:DatePicker, TimePicker的中是依靠dateString、timeString來返回值,並且沒有name值。Checkbox是依靠event.target.checked來返回值,並且還要給其內容傳遞值。code
爲什麼不直接使用form組件?由於不符合UI同窗的需求,不符合產品同窗的需求。這種自由的組合形式,在擴展上,是最合理的。orm
收集好共性,以及差別性以後,能夠思考如何用數據的形式組合。好吧這裏想都不用想json-schema
是最優解。cdn
例如:blog
{
reset:[{// 複製重置數據
name: 'string',// 對應的name
value: 'string|number',// 初始值
}],
map:[
{
type: 'input',// 類型
label: '',// title
name: '',// return的name值
value: '',// return的value值,以及初始值
},
{
type: 'time',// 類型
label: '',// title
name: '',// return的name值
value: '',// return的value值,以及初始值
},
{
type: 'checkbox',// 類型
label: '',// title
name: '',// return的name值
value: '',// return的value值,以及初始值
},
{
type: 'date',// 類型
label: '',// title
name: '',// return的name值
value: '',// return的value值,以及初始值
},
]
}
複製代碼
抹平onChange差別,這裏我會包裝DatePicker、TimePicker、Checkbox、Input的onChange方法,統一返回{name: '',value: ''}
,這樣業務層的處理就能高度統一。接口
最後成果
form組件
接口設計:
col
,控制行數$emitReset(e)
,點擊重置回調,返回重置以後的數據$emitSubmit(e)
,點擊提交回調,返回提交的數據reset
,重置的數據結構map
,表單的數據結構Checkbox組件
接口設計:
name
,返回名value
,默認值label
,顯示名onChange(e)
,變化回調Input組件
接口設計:
name
,返回名value
,默認值label
,顯示名onChange(e)
,變化回調DatePicker組件
接口設計:
name
,返回名value
,默認值label
,顯示名onChange(e)
,變化回調TimePicker組件
接口設計:
name
,返回名value
,默認值label
,顯示名onChange(e)
,變化回調合理規劃的關注的點在於,如何抹平差別、如何合理組合、如何固化需求。其中所要信奉的代碼原則,無非是高解偶、容擴展、少改動。
我一直很喜歡react的核心理念UI=render(data),這是現今最適合GUI範疇的理念沒有之一。