組件化
應用??
頁面??
模塊??
組件??
組件與組件之間的關系是組合不是依賴
資源加載路徑的層級問題? ../../components/xx/xx.js
組件應該是獨立的、無依賴的,如果有耦合,提升到模塊的層面。
SPA 在首次加載頁面時就獲取了所有必需的資源,或者再按需動態(tài)加載并且渲染到頁面上
base 所有控件只定義基色
基色基礎上+1 表示鼠標事件樣式 比如,基色為:#fff; 那么鼠標事件樣式:#
一個網(wǎng)頁是由各種表單、表格、按鈕、輸入控件等組成,那么從更微觀的一個層面去看,這些組件其實都是由線條,線條陰影,圓直角,背景,文字圖片內容,留白加上鼠標事件樣式構成的。
bootstrap 引入往往千篇一律,如果說它解決了前端開發(fā)工程中的有無問題,那么發(fā)展到現(xiàn)階段,應該出現(xiàn)像vui這樣最優(yōu)的選擇。
想法:
應該依據(jù)html元素在游覽器里的渲染順序
應該定義一套UI設計規(guī)范,包含組件的字體,字號,邊框,邊距,組件間間距
- 定義組件基礎樣式,邊框、邊距、字體、字號,每種組件定義大、中、小三種
- theme.css/theme.config 所有組件默認繼承theme.css 配色,也可以為每個組件單獨定義theme.css主題配色。
- 背景
- color
- :hover樣式
- 透明度
- layout
基于24列格柵,
通過flex.layout.css切換flex布局
.col-設置列寬 .col-offset-設置列便宜 col-order-*設置排序
layout
配置文件:
web端
手機端
- flex布局
- 響應式布局
設計模式:
* 導航
* 表單
表單作為獲取用戶輸入的重要交互方式,也承擔將問題和答案配對的角色
??注意事項:
- 敏感信息 通過 “輸入提示” 說明為什么要這么做 eg: 身份證和電話號碼
- 避免在空白中完成輸入。通過“默認值”、“輸入提示/提醒”、“結構化格式”等方式提示用戶
- 即時校錯,并盡可能寬容。eg:多輸空格默認刪掉,不需要提醒用戶
包含:標簽、輸入框、校驗反饋、action
交互:
- 對齊方式-按鈕組與輸入框左對齊 (左對齊、右對齊、頂部對齊)
- 禁用主按鈕(輸入框3個以下)
- 結構化大格式,不接受偏離期望的格式。 eg:銀行卡號輸入框
- 輸入提示 vs 輸入提醒
- 校驗 提前開始校驗錯誤,避免點擊提交之后才反饋
間距規(guī)范:
- 說明文字與表單控件間距 (8px)
- 兩組表單控件間距 (橫排:16px;豎排:24px)
* 列表
- 獲取概覽
- 逐項瀏覽
- 查找特定列表項
- 排序與過濾
- 重新安排、添加、刪除或重新分類列表項
交互:
- 顯示詳情 鼠標懸停某個鏈接或內容時,顯示該項列表少量詳情信息 移入0.5s延時
- 列表嵌入 通過點擊查看詳情信息,顯示在當前上下文 兩層折疊面板
- 彈層顯示
- 面板選擇器 通過選擇后在右側彈出該列表大量詳情信息
- 單窗口深入
- 分頁器
- 無限加載 監(jiān)聽滾輪事件或者單擊按鈕
* 表格
內容:
- 按鈕組
- 搜索
- 排序
- 篩選 (eg:用戶上線狀態(tài))
- 狀態(tài)點 (完成、進行中、異常、未開始)
- 單行操作 (更多操作)
- 分頁器/無限加載(可選)
交互:
- 顯示長表格
- 全選數(shù)據(jù)
- 跨頁選數(shù)據(jù)
- 固定按鈕組
- 過長內容自動隱藏 鼠標懸浮時顯示完整
- 表格項編輯 模塊編輯 、直接單元格編輯 、懸浮層編輯
間距規(guī)范:
行高:
大:表格主體 跟表格標題和分頁按鈕間距16px,表頭上下內邊距11px,表格行上下內邊距16px、左右邊距8px
中:表頭與表格行上下內邊距為10px
小:表頭上下內邊距10px,表格行上下內邊距6px、左右邊距8px
列寬:
表頭不換行,固定字節(jié)長度大列盡量不換行(時間/操作等)
對齊方式:
數(shù)值右對齊,帶小數(shù)點按小數(shù)點對齊;
其余左對齊;
表格增強:
多列數(shù)據(jù): 通過按鈕實現(xiàn)左右切換;自定義顯示列項;固定表頭橫向滾動顯示;
帶圖標帶表格:eg:通過圖標表達數(shù)據(jù)變化趨勢
帶圖表帶表格:
二維拓展表格:橫向縱向各一個標題
簡化表格:卡片和彈出框展示表格
* 搜索
十大設計原則
親密性 Proximity
信息之間關聯(lián)性越高距離應該越接近,像一個視覺單元;親密性的目的是實現(xiàn)組織性,讓用戶對頁面結構和信息層次一目了然。
縱向間距:
- 8px(小號間距)、16px(中號間距)、24px(大號間距)
- 特殊情況可以通過加減『基礎間距』的倍數(shù),或者增加元素來拉開信息層次
- y=8+8*n。其中,n>=0,y 是縱向間距,8 是『基礎間距』
- 通過增加『分割線』來拉開層次
橫向間距:
對齊 Alignment
心理學『格式塔學派』中連續(xù)律:在知覺過程中人們傾向于使知覺對象的直線繼續(xù)成為直線,曲線繼續(xù)成為曲線。在設計中,將元素進行對齊,既符合用戶的認知特性,也能引導視覺流向,讓用戶更流暢地接收信息。
文字對齊: 字段或段落較短、較散時統(tǒng)一一個視覺起點
表單對齊: 冒號(右)對齊;順著冒號視覺流,能方便快速填寫表單項
數(shù)字對齊: 建議取相同有效位數(shù),右對齊;可快速比對數(shù)值大小
對比 Contrast
對比增加視覺效果,同時也能在不同元素之間建立一種有組織的層次結構,讓用戶快速識別關鍵信息。
重復 Repetition
相同的元素在整個界面中不斷重復,不僅可以有效降低用戶的學習成本,也可以幫助用戶識別出這些元素之間的關聯(lián)性
線框重復、設計要素重復、文案格式重復。
重復元素可以是一條粗線、一種線框,某種相同的顏色、設計要素、設計風格,某種格式、空間關系等。
直截了當 Make it Direct
需要在哪里輸出,就要允許在哪里輸入。這就是直接操作的原理。不要為了編輯內容而打開另一個頁面,應該直接在上下文中實現(xiàn)編輯。
頁內編輯:
單擊編輯:當『易讀性』遠比『易編輯性』重要時,使用單擊編輯。
狀態(tài)一:普通的瀏覽模式,不區(qū)分可編輯行和不可編輯行;
狀態(tài)二:鼠標懸停時,『指針』變?yōu)椤菏中汀唬庉媴^(qū)域底色變黃,出現(xiàn)『Tooltips』提示單擊編輯;
狀態(tài)三:鼠標點擊后,出現(xiàn)『輸入框』、『確定』、『取消』表單元素,同時光標定位在『輸入框』中。
文字鏈/圖標編輯示例
狀態(tài)一:在可編輯行附近出現(xiàn)文字鏈/圖標;
狀態(tài)二:鼠標點擊『編輯』后,出現(xiàn)『輸入框』、『確定』、『取消』表單元素,同時光標定位在『輸入框』中
當『易讀性』為主,同時又要突出操作行的『易編輯性』時,可使用『文字鏈/圖標編輯』。
簡化交互 Keep it Lightweight
足不出戶 Stay in the Page
提供邀請 Provide Invitation
巧用過渡 Use Transition
即時反應 React Immediately
推論邀請:用于交互期間,合理推斷用戶可能產(chǎn)生的需求。
推論邀請示例
用戶點擊『贊』后,同時系統(tǒng)分析(既然用戶喜歡這篇文章,那么可能對這一類文章都有興趣)并提供開啟『精打細算』的邀請。
分析:這里的推論邀請設置不合理方面:‘下次再說’ 應該改為 “3s 后退出/關閉”。雖然推論合理,但你不能代替用戶思維。設置自動退出以不影響用戶操作。
一個控件有哪幾種狀態(tài)形式?
- 禁止??? state-disabled disabled="disabled"
- 報錯? state-error
- 成功? state-success
- 警告?? state-warning
- 進行中 ?? state-validating
- 其它包括:
- :hover
- :focus
- :active
- :visited
架構:應用-頁面-模塊-組件
應用-路由-模塊-組件(單頁應用)
組件間應該是獨立的、無依賴的;
app.config.json 配置文件:
- [x] 文件目錄組織結構
- [ ] 手機端 or web端
組件模式架構實現(xiàn)思路:
繼承機制:
store 概念:組件不是直接從服務端取數(shù)據(jù),而是到對應的前端數(shù)據(jù)緩存中獲取數(shù)據(jù)。緩存與服務端同步。
數(shù)據(jù)與dom:當數(shù)據(jù)變動,dom結構自動變動。即把大多數(shù)命令式的dom操作簡化為配置操作。
components目錄下, 一個目錄為一個組件,引入方式可以是這樣:
<div include=“components/Employee-panel”></div> or
<div include=“components/Employee.html”> or
<div include=“components/Employee.js”>業(yè)務模型(純邏輯)
視圖模型(基本也是純邏輯)
界面層(多是字符串模板)
同一個視圖模型搭配不同的界面模板,可以實現(xiàn)視圖模型的復用 ;同一個界面模板與不同的視圖模型組合,也能直接組合出完全不同的東西 所以這么一來,我們的復用粒度就非常靈活了
框架不關注組件內部實現(xiàn),關注組件的數(shù)據(jù)存取接口
框架應當盡可能以web components 為基石
變更檢測:通過某種配置的方式,由框架自動添加一些關聯(lián),當數(shù)據(jù)變更的時候,把DOM進行相應修改,又比如,當DOM發(fā)生變動的時候,也更新對應的數(shù)據(jù)
組件同數(shù)據(jù)間實現(xiàn)一個有限狀態(tài)機(數(shù)據(jù)更新前,正在更新,更新之后等等)
服務器推送一條數(shù)據(jù)——store緩存更新——界面更新前準備——界面更新中——完成更新
提交數(shù)據(jù)——store緩存更新——界面更新(多個狀態(tài)步驟)——
|同時——提交服務器——反饋成功與否——通知store——界面狀態(tài)更新
變更檢測的幾種實現(xiàn)方式:
存取器封裝。對數(shù)據(jù)進行包裝。一種方式是通過geter與seter函數(shù);另一種在一些新的游覽器也可以用defineProperty相關方法。
var data = {
name: "aaa",
getName: function() {
return this.name;
},
setName: function(value) {
this.name = value;
}
}臟檢測:(angular@1.x)保存數(shù)據(jù)舊值與新值,事件發(fā)生后的數(shù)據(jù)跟舊數(shù)據(jù)比對,有不同再觸發(fā)界面刷新。控制可能導致數(shù)據(jù)刷新的來源(各種事件);
觀察機制:在ES7里引入了Object的observe方法,可以用于監(jiān)控對象或數(shù)組的變動。所謂觀察機制,也就是觀測對象屬性的變更,數(shù)組元素的新增,移除,位置變更等等。
觀察機制:
DOM也是可以被觀察的,但是目前絕大多數(shù)雙向同步框架都是通過事件的方式把DOM變更同步到數(shù)據(jù)上。
事件方式的問題:
- 某個文本框綁定了一個對象的屬性,框架內部是監(jiān)控了這個文本框的鍵盤輸入、粘貼等相關事件,然后取值去往對象里寫。但是如果你直接myInput.value=”111”,這個變更就沒法獲取了。可以從HTMLInputELement的原型上去覆蓋value賦值,嘗試把這種東西也納入框架管轄范圍。
- 另外一個問題,那就是我們只考慮了特定元素的特定屬性,可以通過事件獲取變更,如何獲得更廣泛意義上的DOM變更?比如說,一般屬性的變更,或者甚至子節(jié)點的增刪?
- DOM4引入了MutationObserver,用于實現(xiàn)這種變更的觀測。
- polymer實現(xiàn)了一個observe-js,用于觀測數(shù)組、對象和路徑的變更
理解一個問題:
界面控件綁定了一個for循環(huán)1000次的數(shù)據(jù)a
for(var i = 0; i<1000; i++){
obj.a+=1;
}
對框架來說,中間過程必須全都舍棄。react使用了虛擬DOM來減少中間的dom操作浪費;界面只響應邏輯變更的結束狀態(tài),不響應中間狀態(tài)。同樣,dom的寫入應該是一次性寫入的(通過DocmentFragment或者innerHTML一次寫入整個字符串)
Immutable Date 函數(shù)式編程當中的一個概念
其大致理念:任何一種賦值,應該被轉化成復制而不是引用。不存在指向同一個地方的引用。
外層數(shù)據(jù)——list組件(從外層復制一份數(shù)據(jù))
外層數(shù)據(jù)arr改變——同步給內層list組件數(shù)據(jù)更新——list組件界面跟新
list組件產(chǎn)生操作事件——改變list組件數(shù)據(jù)——通過immutable data將數(shù)據(jù)跟外層同步一份
思考一個問題,沒有復用度的東西到底需不需要拆出去,成為一個組件?
所謂組件化,其核心意義在于提取真正有復用價值的東西、更好的組織代碼結構以及提升可維護性,哪些東西有復用的價值呢?
- 控件
- 基礎邏輯功能
- 公共樣式
- 穩(wěn)定的業(yè)務邏輯
模版和函數(shù),兩種對UI層組件化的處理方式:
- 模版(字符串):用html字符串的方式去表達界面結構,通過代入數(shù)據(jù)生成真正的界面。只生成html的叫靜態(tài)模版,同時還生成事件綁定的叫動態(tài)模版。
- 函數(shù):react之類。其內部可能還是使用模版,但在外封裝一層,可以對不同平臺提供相同接口,統(tǒng)一調用方式。
界面模版:
可視為一種配置文件。某一塊界面模版描述自身與數(shù)據(jù)模型的關系。當被解析后,按照設置與數(shù)據(jù)建立關聯(lián),且更新自身所對應的視圖。
通過示例來展示某個簡單的組件(widget)的演化過程,看它是如何從一個龐大的、缺乏結構性的代碼庫進化為一個可重用的組件的:
html5 的元數(shù)據(jù)和微格式:
微格式:一種簡單的、開放的數(shù)據(jù)格式。主要包括hCard,hCalendar,hAtom這幾種。
項目整體方案
基礎框架
業(yè)務代碼規(guī)劃
ui組件規(guī)劃
樣式主題定制
構建方案
協(xié)作方式
我們要做的是:分層隔離
ui層(View):
業(yè)務邏輯 (Controller/ViewModel):
數(shù)據(jù)層(Model):Relay/GraphQL/Falcor /super agent / Fetch
falcor 優(yōu)化前后端通信,將所有的后臺數(shù)據(jù)通過一個虛擬的json提供給前端
自己的理解 graphQL 使用一個GraphQL一次性將一個聚合根傳遞到前端(比分解成一個個json節(jié)省網(wǎng)絡開銷)
組件化,關注點分離
react 優(yōu)點
- 以最高效率去更新dom的更新部分
- 數(shù)據(jù)結構不可變,意味著組件狀態(tài)不可變,組件變成可重用。
GraphQL的動機:
應該為組件通過聲明的方式聲明指定的數(shù)據(jù),而不是在組件運行中通過命令方式去抓取數(shù)據(jù);既然我們不用在組件中去抓取數(shù)據(jù),那么可以將這些多次的數(shù)據(jù)請求放在一起一次性發(fā)出一個請求,以獲得所必需的數(shù)據(jù)。這樣我們在增加或移除組件時就可以不用考慮跟蹤這些組件所需要的后端數(shù)據(jù)資源。
聲明式編程風格 聲明你想要什么,不關注細節(jié),eg:一條SQL語句取得我們想要的數(shù)據(jù),至于具體如何取得那是數(shù)據(jù)庫的事
命令式編程風格 需指定詳細的獲取步驟
數(shù)據(jù)源
遠程 請求遠程服務獲得
本地 紀錄用戶操作的狀態(tài)
問題:
遠程數(shù)據(jù)同步 :實時遠程請求 or falcor
組件間數(shù)據(jù)同步:組件共享一個model
遠程數(shù)據(jù)實現(xiàn)緩存和同步?用falcor 圖形結構
Model分為datamodel域uimodel , datamodel 關聯(lián)遠程數(shù)據(jù)源,uimodel 存儲本地ui操作數(shù)據(jù)
組件化開發(fā) vs 模塊化開發(fā)
目前社區(qū)在某種無意識的混淆這兩個概念,組件化開發(fā)是模塊化開發(fā),但模塊化開發(fā)不能說就是組件化開發(fā);兩者的關系是:(組件化>模塊化);
組件化問題:
- 組件css作用域隔離
- 主題配色css全局文件
組件應該是一個成品(至少是半成品)的概念,對比汽車行業(yè),整車的制造由各個組件或部件組合而成;單個組件由特定的功能和外觀樣式組合而成,所以組件并不只是具有某種功能屬性,還包括它的外觀樣式屬性。
組件分為基礎組件和高級組件,基礎組件當然更多的是復用;高級組件更多的是分治;我們做組件化開發(fā)是要在基礎組件上做高級組件開發(fā)。
組件框架本身是基于模塊化機制搭建的,模塊機制作為組件機制的基礎。一個組件是一個模塊;