摘要:正文距離第一篇組件庫文章發布已經過去個月了,在此期間利用零零散散的時間持續更新組件庫,目前移動端組件庫已經更新大類基礎表單彈出層種組件供使用。鏈接組件庫從到開發心得主頁更改版版方案祝工作順利鄧文斌年月日
正文
距離第一篇UI組件庫文章發布已經過去3個月了,在此期間利用零零散散的時間持續更新owl-ui組件庫,目前owl-ui移動端組件庫已經更新3大類(基礎、表單、彈出層)9種組件(Button、Tabs、Input、Select、Switch、Drawer、Dialog、Picker、Toast)供使用。本篇文章主要講述我在這3個月內開發UI組件的個人心得。如果想了解項目結構可以閱讀上一篇文章,如果想了解實現原理可以閱讀源碼。所有連接在文章的結尾處。
我們從彈出層組件講起
前方多圖預警
先看效果圖。
我在選擇寫組件的時候,首先選擇做彈出層部分。為什么呢?我列出以下幾點。
共性高、可復用。
兼容性高。
快速出貨,提升成就感。
先說第一點:共性高、可復用
因為本人非常笨,所以做事之前需要構思很久,這樣會減少之后重復性的工作。比如在做彈出層的時候,不少人會發現以上組件的共同點。沒錯,他們都是顯示或隱藏(廢話)。我們接著往下分析,除了顯示或隱藏之外,他們大部分都有遮罩層部分。還有動畫效果也一致。我們先根據這幾點把功能抽象出來,如何做呢?
在vue和less中都有mixins方式,根據mixins我們很方便的將組件中的共性提取出來,達到代碼精簡的目的。以下代碼就是彈出層組件中顯示或隱藏功能的mixins文件。
// src/common/mixins/visibility.js
const EVENT_TOGGLE = "toggle"
export default {
model: {
prop: "visible",
event: EVENT_TOGGLE
},
props: {
visible: {
type: Boolean,
default: false
},
zIndex: {
type: Number,
default: 100
},
maskStyle: {
type: Object,
default: () => {}
},
containerStyle: {
type: Object,
default: () => {}
}
},
data () {
return {
isVisible: false
}
},
methods: {
hide () {
this.isVisible = false
},
show () {
this.isVisible = true
}
},
watch: {
isVisible (val) {
this.$emit("update:visible", val)
this.$emit("callback", val)
if (this.lockScroll) {
document.body.style.overflow = val ? "hidden" : ""
}
},
visible: {
handler (val) {
this.isVisible = val
}
}
},
beforeDestroy () {
this.lockScroll && (document.body.style.overflow = "")
}
}
上面主要做一件事,根據visible屬性判斷組件展示或隱藏。
使用方式如下:
// 組件文件
順便說一下項目中運用到less的mixins運用,比如1px問題。
// src/styles/common/border.less .min-device-pixel-ratio(@scale2, @scale3) { @media screen and (min-device-pixel-ratio: 2), (-webkit-min-device-pixel-ratio: 2) { transform: @scale2; } @media screen and (min-device-pixel-ratio: 3), (-webkit-min-device-pixel-ratio: 3) { transform: @scale3; } } .border-1px(@color: #DDD, @radius: 2PX, @style: solid) { &::before { content: ""; pointer-events: none; display: block; position: absolute; left: 0; top: 0; transform-origin: 0 0; border: 1PX @style @color; border-radius: @radius; box-sizing: border-box; width: 100%; height: 100%; @media screen and (min-device-pixel-ratio: 2), (-webkit-min-device-pixel-ratio: 2) { width: 200%; height: 200%; border-radius: @radius * 2; transform: scale(.5); } @media screen and (min-device-pixel-ratio: 3), (-webkit-min-device-pixel-ratio: 3) { width: 300%; height: 300%; border-radius: @radius * 3; transform: scale(.33); } } } .border-top-1px(@color: #DDD, @style: solid) { &::before { content: ""; position: absolute; left: 0; top: 0; width: 100%; border-top: 1Px @style @color; transform-origin: 0 0; .min-device-pixel-ratio(scaleY(.5), scaleY(.33)); } }
該函數可以通過傳參改變線的顏色和類型。
使用方式如下:
// src/styles/packages/dialog.less @import "../common/border"; @dialog-prefix-cls: ~"@{css-prefix}dialog"; .@{dialog-prefix-cls} { ... &-btns { ... .border-top-1px(); // Here } }
合理的運用mixins可以使得項目結構清晰、減少冗余代碼更利于后期維護。
優化方式有很多種,每個人有不同的編碼習慣,因人而異。但是目標都是一致的,讓自己的代碼變得簡潔、精煉和易讀。
在彈出層中將公共部分抽象封裝,比如遮罩層
// src/common/components/popup-mask.vue
第二點:兼容性高
我在工作中接觸的移動端需求比較多,PC端做過一些管理后臺。移動端與PC端的項目,給我最最直觀的感受是,移動端要求UI極其嚴格,一像素都不能差,而PC端差不多就可以了,UI設計師們也不會過多糾結PC端做出來的頁面是否跟原型圖完全吻合。
在移動端,有的產品特別喜歡更改UI設計,特別是有表單部分的頁面,今天產品嫌棄字體小了,明天可能覺得字體又太大了;今天把輸入框改成圓角,明天就喜歡直角。今天覺得橫向布局好,沒準明天就要試試縱向布局。產品覺得這么改不要緊,殊不知如果項目中運用了UI組件庫,這么修改完后,代碼冗余太多。都是為了更好的用戶體驗,慢慢也能理解。在那之后的幾個移動端項目里,表單部分基本不會用到UI組件庫。但是彈出層部分沒有過多的限制,據我了解到的產品內部最統一的就是彈出層。如果有同學想用owl-ui的彈出層部分的話,可以放心用,支持按需加載。
第三點:快速出貨,提升成就感
我喜歡把長期計劃拆解成多個很小的事情來做,就是制定很多小目標。好比游戲進度條一樣,使其量化。之所以這么做的原因是,我能周期性的看到我的工作成果,這樣可以激勵自己,提升信心。
在彈出層組件中,mixins做好之后,像toast、dialog、drawer組件只剩下設計api部分而已。而picker組件是基于drawer組件來實現的內容部分而已。當picker組件實現完成,這時已經說明表單的select組件也已經完成了。說起來簡單,其實做起來也不難。
最后在使用彈出層組件時,我想用api調用的方式來使用它。這里我借鑒了cube-ui的vue-create-api,但是因為部分方法不太適合我,所以我稍加改動,借鑒(抄)到自己的庫中。
比如Toast組件,官網給出的使用方式如下:
const toast = this.$createToast({ time: 1000, txt: "Toast time 1s" }) toast.show()
我是個懶人,對我來說使用一個消息提醒要寫這么多,我就覺得很煩惱,所以我在owl-ui中把vue-create-api稍加改造后,Toast使用方式如下:
this.$toast("歡迎光臨")
清爽了很多。
其他類型組件使用情況,有人喜歡整套使用,有人喜歡部分使用。而我屬于后者。
結語
我寫組件庫的目的就兩點。第一點可以幫助我重新梳理一遍vue的知識體系,了解到自身的不足,不斷的克服困難,讓自己成長。第二點結識更多圈內的朋友,提高見識。我會持續更新迭代owl-ui組件庫,歡迎喜歡技術的朋友多提建議。最后附上吳軍博士說過話,這句話讓我終身受益。
什么事情從0分做到50分靠常識,從50分做到90分靠技術,從90分做到100分靠的是藝術。做到90分我們可以通過努力能達到,至于是否能做到更好,就依人而定了。
鏈接
UI組件庫從0到1開發心得
github
owl-ui主頁
vue-create-api更改版
less版1px方案
祝工作順利
鄧文斌
2019年5月20日
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/6660.html
摘要:最好能使用一套模板渲染前后端的數據,也就是模板和某些簡單組件可以同構。開發組件因為需要讓服務端也能使用,單文件的開發方式我目前是沒有找到可以讓讀取的方式,所以就暫時放棄了。這種通用組件寫法只適合比較簡單的項目。 項目情況 我使用的是express做為服務器框架,只需要調用后臺API接口獲得數據,然后把數據渲染成html就可以了。最好能使用一套模板渲染前后端的數據,也就是模板和某些簡單組...
摘要:控制數據流屬于最強的開發規范,必定會給開發業務的同學帶來巨大的思維挑戰,從系統整體質量和維護性來看,必須犧牲業務開發的編程自由度。 引入的背景 在一個龐大的商業系統中引入react這種數據驅動的模式。 希望能夠一點點重構去替換以前的模塊,逐步的將系統重要部分底層框架替換成react。 同事實踐的心得 以下內容都摘自同事使用后的一些感想 心得一 從過程化開發向面向數據的開發轉化。后者要...
摘要:目前開發的項目中為了仿原生效果如果自己去通過重新實現的話成本極大所以不得不使用來作為前端庫。可以在這個函數中清理在綁定的事件這個方式很有用。在開發過程中這些生命周期函數是我使用最頻繁最常見的操作。 ReactJS作為目前最火的構建用戶界面的前端框架,為什么有那么多的前端工程師去追逐它,不僅因為它簡單,而且它提供了一系列強大的API讓我們擺脫以前繁瑣的DOM操作,使我們的邏輯更加清晰,代...
閱讀 1084·2023-04-25 14:35
閱讀 2837·2021-11-16 11:45
閱讀 3435·2021-09-04 16:48
閱讀 2194·2021-08-10 09:43
閱讀 540·2019-08-30 13:17
閱讀 1635·2019-08-29 13:27
閱讀 902·2019-08-26 13:58
閱讀 2164·2019-08-26 13:48
极致性价比!云服务器续费无忧!
Tesla A100/A800、Tesla V100S等多种GPU云主机特惠2折起,不限台数,续费同价。
NVIDIA RTX 40系,高性价比推理显卡,满足AI应用场景需要。
乌兰察布+上海青浦,满足东推西训AI场景需要