來來，一起設計一個簡單的活動發布系統

前言

前段時間我寫了一篇博客：小公司的前端應該怎么做？，其中核心的幾個觀點之一就是要把重復工作給干掉！

而我們日常工作中有一類需求名曰活動，這些活動就像臟水一樣不停的向我們涌來，而且要的又急，這個時候有些團隊就會疲於奔命的去讓前端做頁面然后走發布流程，如果你的公司是這樣，業務發展后再多幾個前端也不夠。

我這里說的活動大概分為四類：

① 描述性活動（或者說簡單類文案）

這種直接做一個類似新聞發布系統的東西即可，這里不予討論。

② 有規律類模塊化活動

這里活動的場景比較多，一般是有文字，有圖片，有一些簡單的商品操作，甚至有投票統計。

③ 無規律定制化活動

這里活動基本我們沒法辦法了，他可能做成一個H5的游戲之類的活動，這種只能重新開發。

④ 內嵌類活動

這種活動一般是與大公司合作時候，大公司某一塊產品會留一塊區域給你加載你的js活動：

這類活動比較特殊，比如貼吧給出來的區域是給京東的廣告位，而貼吧登錄情況下可以拿到你手機號，他如果將這個手機號傳給京東廣告位的話，那么京東可能就會對你進行定向推送。

我們一般不會將js載入的權限放給其他公司，但是卻可能放給自己公司的兄弟部門，比如我這里有一塊區域就是留給自己部門的人的廣告位：

js載入后（有時候為了新能會直接一起吐出來），便能將區域顯示出來了，當然為了防止一個部門影響全局，影響其它部門的元素，會有很多限制，比如不能操作自己dom以外的元素。

我們今天重點討論第二種場景的設計。

文中是我個人的一些開發經驗，希望對各位有用，也希望各位多多支持討論，指出文中不足以及提出您的一些建議。

活動模板

我們要實現一個簡單的活動發布平台，簡單來說就是一個活動發布ide，讓運營或者市場同事都可以自己發活動，沒一個活動子項目都是一個組件，這里會實現：

① 標題

② 正文

③ 圖片

④ 鏈接

⑤ 投票

⑥ 產品組件

如果不加入投票產品等組件，一個富文本編輯器便能實現需求，但是考慮了后期還有更多擴展，通用發布系統不可避免，做出來大概是這樣的：

數據庫設計

PS：我這里使用localstorage做簡單數據庫

明白了需求，就應該做數據庫概要設計，這里首先有一個活動表：

//活動表
var  activity = {
    id: '唯一id',
    title: '活動標題'
}

這個活動表是比較特殊的，因為他的內容全部是一個個小的組件，於是我們會有一個組件表：

//組件類型
var widget = {
    id: '唯一id',
    name: '組件名字',
    typeId: '組件類型'
}

由於json數據的出現，有點模糊了一些表與表的一些界限，我們也可以在activity中包含一個widgets字段，記錄這個活動擁有哪些組件，這樣對維護來說應該不太好，還是單獨分開好，所以這里有個關聯表：

//一個活動擁有哪些組件,與活動表與組件表為外鍵約束
var activity_widget = {
    activityId: '活動id',
    widgetId: '組件id'
}

但是每個組件表實現各異，我們要去維護一個個組件各自的表現太過麻煩，而提現在前端dom上事實上僅僅需要的是數據，而這里就使用了json的好處，改變了組件表，並新增了組件類型表：

/*
組件類型,可能的數據為:
這里嚴格一點的話可以 {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測算，我們可以知道數據表設計的是否合理，如果基本驗證通過，便可以在這個基礎上進行更加完善的設計，如果發現不對就改變方案。

比如說，我們這里已經創建了一個活動：

var actId = _.uniqueId('activity_');

var activity = {
    id: actId,
    title: '活動測試'
};

這個時候我們為該活動添加一個title、一個img、一個投票三個組件就是這樣的：

//首先實例化三個組件
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: []}
};

然后將組件與活動關聯起來：

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