前言
前段時間我寫了一篇部落格:小公司的前端應該怎麼做?,其中核心的幾個觀點之一就是要把重複工作給幹掉!
而我們日常工作中有一類需求名曰活動,這些活動就像髒水一樣不停的向我們湧來,而且要的又急,這個時候有些團隊就會疲於奔命的去讓前端做頁面然後走釋出流程,如果你的公司是這樣,業務發展後再多幾個前端也不夠。
我這裡說的活動大概分為四類:
① 描述性活動(或者說簡單類文案)
這種直接做一個類似新聞釋出系統的東西即可,這裡不予討論。
② 有規律類模組化活動
這裡活動的場景比較多,一般是有文字,有圖片,有一些簡單的商品操作,甚至有投票統計。
③ 無規律定製化活動
這裡活動基本我們沒法辦法了,他可能做成一個H5的遊戲之類的活動,這種只能重新開發。
④ 內嵌類活動
這種活動一般是與大公司合作時候,大公司某一塊產品會留一塊區域給你載入你的js活動:
這類活動比較特殊,比如貼吧給出來的區域是給京東的廣告位,而貼吧登入情況下可以拿到你手機號,他如果將這個手機號傳給京東廣告位的話,那麼京東可能就會對你進行定向推送。
我們一般不會將js載入的許可權放給其他公司,但是卻可能放給自己公司的兄弟部門,比如我這裡有一塊區域就是留給自己部門的人的廣告位:
js載入後(有時候為了新能會直接一起吐出來),便能將區域顯示出來了,當然為了防止一個部門影響全域性,影響其它部門的元素,會有很多限制,比如不能操作自己dom以外的元素。
我們今天重點討論第二種場景的設計。
文中是我個人的一些開發經驗,希望對各位有用,也希望各位多多支援討論,指出文中不足以及提出您的一些建議。
活動模板
我們要實現一個簡單的活動釋出平臺,簡單來說就是一個活動釋出ide,讓運營或者市場同事都可以自己發活動,沒一個活動子專案都是一個元件,這裡會實現:
① 標題
② 正文
③ 圖片
④ 連結
⑤ 投票
⑥ 產品元件
如果不加入投票產品等元件,一個富文字編輯器便能實現需求,但是考慮了後期還有更多擴充套件,通用釋出系統不可避免,做出來大概是這樣的:
資料庫設計
PS:我這裡使用localstorage做簡單資料庫
明白了需求,就應該做資料庫概要設計,這裡首先有一個活動表:
1 2 3 4 5 |
//活動表 var activity = { id: '唯一id', title: '活動標題' } |
這個活動表是比較特殊的,因為他的內容全部是一個個小的元件,於是我們會有一個元件表:
1 2 3 4 5 6 |
//元件型別 var widget = { id: '唯一id', name: '元件名字', typeId: '元件型別' } |
由於json資料的出現,有點模糊了一些表與表的一些界限,我們也可以在activity中包含一個widgets欄位,記錄這個活動擁有哪些元件,這樣對維護來說應該不太好,還是單獨分開好,所以這裡有個關聯表:
1 2 3 4 5 |
//一個活動擁有哪些元件,與活動表與元件表為外來鍵約束 var activity_widget = { activityId: '活動id', widgetId: '元件id' } |
但是每個元件表實現各異,我們要去維護一個個元件各自的表現太過麻煩,而提現在前端dom上事實上僅僅需要的是資料,而這裡就使用了json的好處,改變了元件表,並新增了元件型別表:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
/* 元件型別,可能的資料為: 這裡嚴格一點的話可以 {title: string},我們這裡只是demo就不太較真 */ var wiget_type = { id: '唯一標識', data: '描述資料格式的json串' }; //因為我們暫時只有6個元件型別便直接窮舉出所有元件的資料型別 var wiget_type = { //title類元件只包含title欄位 title: 'title', content: 'content', img: 'src,alt,link', link: 'title,link', vote: 'items', product: 'id,img,title' }; //元件型別 var widget = { id: '唯一id', name: '元件名字', data: '真實的資料json串', typeId: '對應元件型別' } |
簡單資料庫設計結束,我們並不能肯定我們設計的合理性,這個時候就需要簡單驗證了。
驗證設計
驗證資料設計,即為我們的簡單demo階段,根據demo測算,我們可以知道資料表設計的是否合理,如果基本驗證通過,便可以在這個基礎上進行更加完善的設計,如果發現不對就改變方案。
比如說,我們這裡已經建立了一個活動:
1 2 3 4 5 6 |
var actId = _.uniqueId('activity_'); var activity = { id: actId, title: '活動測試' }; |
這個時候我們為該活動新增一個title、一個img、一個投票三個元件就是這樣的:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
//首先例項化三個元件 var widgetTitle = { id: wTitleId, type: 'title', //編輯部分 data: {title: ''} }; var widgetImg = { id: wImgId, type: 'img', data: {src: '', alt: '', link: ''}, }; var widgetVote = { id: wVoteId, type: 'vote', data: {items: []} }; |
然後將元件與活動關聯起來:
1 2 3 4 |
var activity_widget = { activityId: actId, widgets: [wTitleId, wImgId, wVoteId] }; |
這裡再搭配起我們的前端模板,可以輕易的將一個活動的類容給展示出來:
在初步的使用中,我也認識到,關於不同元件型別編輯情況應該不一樣,之前考慮的太簡單,只有字串的場景,而投票這種元件是陣列的情況,後續還可能出現更加複雜的資料結構,顯然上述設計是不能完全滿足條件的。
修正設計
經過思考,我這裡產生了一個新的思路:
① widget_type中存取的是預設資料
② 我們針對每一個type會有一個特別的js控制器
這個思路來源於我做單頁應用,我一個頁面片會有一個頁面處理程式,所以一個型別的元件也應該有屬於他自己的控制器,因為這個活動元件會具有一個編輯和麵向使用者的展示,可能需要2個控制器,於是我們來驗證這個想法。
有了這個想法後,感覺一個頁面已經不能滿足我了,開始了引入模組化機制,這裡預計的是一個元件具有三種形態,也就是三種控制器:
① 後臺預覽模式
② 後臺編輯模式
③ 使用者瀏覽模式
事實上就是對一種資料結構的三種展示,不同的狀態有不同的表現形式,這裡是投票元件的簡單demo:
至此基本設計得到了驗證,我覺得可以持續在此展開了,至於元件刪除與儲存資料庫就暫時不予實現。
結語
這裡花了一些時間整理工作中的需求,做簡單方案設計,誠然demo中的設計教簡陋,但是隨著一步步將初步構想變成實際專案,就會形成一些高大上的東西啦。
程式碼地址:https://github.com/yexiaochai/module/tree/master/activity
demo地址:http://yexiaochai.github.io/module/activity/index.html