前言
前段時間我寫了一篇部落格：小公司的前端應該怎麼做？，其中核心的幾個觀點之一就是要把重複工作給幹掉！
而我們日常工作中有一類需求名曰活動，這些活動就像髒水一樣不停的向我們湧來，而且要的又急，這個時候有些團隊就會疲於奔命的去讓前端做頁面然後走釋出流程，如果你的公司是這樣，業務發展後再多幾個前端也不夠。
我這裡說的活動大概分為四類：
① 描述性活動（或者說簡單類文案）
這種直接做一個類似新聞釋出系統的東西即可，這裡不予討論。
② 有規律類模組化活動
這裡活動的場景比較多，一般是有文字，有圖片，有一些簡單的商品操作，甚至有投票統計。
③ 無規律定製化活動
這裡活動基本我們沒法辦法了，他可能做成一個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