來來，一塊兒設計一個簡單的活動發佈系統

前言

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

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

我這裏說的活動大概分爲四類：

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

這種直接作一個相似新聞發佈系統的東西便可，這裏不予討論。

② 有規律類模塊化活動

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

③ 無規律定製化活動

這裏活動基本咱們無法辦法了，他可能作成一個H5的遊戲之類的活動，這種只能從新開發。

④ 內嵌類活動

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

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

咱們通常不會將js載入的權限放給其餘公司，可是卻可能放給本身公司的兄弟部門，好比我這裏有一塊區域就是留給本身部門的人的廣告位：

js載入後（有時候爲了新能會直接一塊兒吐出來），便能將區域顯示出來了，固然爲了防止一個部門影響全局，影響其它部門的元素，會有不少限制，好比不能操做本身dom之外的元素。

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

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

活動模板

咱們要實現一個簡單的活動發佈平臺，簡單來講就是一個活動發佈ide，讓運營或者市場同事均可以本身發活動，沒一個活動子項目都是一個組件，這裏會實現：

① 標題

② 正文

③ 圖片

④ 連接

⑤ 投票

⑥ 產品組件

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

數據庫設計

PS：我這裏使用localstorage作簡單數據庫

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

1 //活動表
2 var  activity = {
3     id: '惟一id',
4     title: '活動標題'
5 }

這個活動表是比較特殊的，由於他的內容所有是一個個小的組件，因而咱們會有一個組件表：

1 //組件類型
2 var widget = {
3     id: '惟一id',
4     name: '組件名字',
5     typeId: '組件類型'
6 }

因爲json數據的出現，有點模糊了一些表與表的一些界限，咱們也能夠在activity中包含一個widgets字段，記錄這個活動擁有哪些組件，這樣對維護來講應該不太好，仍是單獨分開好，因此這裏有個關聯表：

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

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

 1 /*
 2 組件類型,可能的數據爲:
 3 這裏嚴格一點的話能夠 {title: string},咱們這裏只是demo就不太較真
 4 */
 5 var wiget_type = {
 6     id: '惟一標識',
 7     data: '描述數據格式的json串'
 8 };
 9 
10 //由於咱們暫時只有6個組件類型便直接窮舉出全部組件的數據類型
11 var wiget_type = {
12     //title類組件只包含title字段
13     title: 'title',
14     content: 'content',
15     img: 'src,alt,link',
16     link: 'title,link',
17     vote: 'items',
18     product: 'id,img,title'
19 };
20 
21 //組件類型
22 var widget = {
23     id: '惟一id',
24     name: '組件名字',
25     data: '真實的數據json串',
26     typeId: '對應組件類型'
27 }

簡單數據庫設計結束，咱們並不能確定咱們設計的合理性，這個時候就須要簡單驗證了。

驗證設計

驗證數據設計，即爲咱們的簡單demo階段，根據demo測算，咱們能夠知道數據表設計的是否合理，若是基本驗證經過，即可以在這個基礎上進行更加完善的設計，若是發現不對就改變方案。

好比說，咱們這裏已經建立了一個活動：

1 var actId = _.uniqueId('activity_');
2 
3 var activity = {
4     id: actId,
5     title: '活動測試'
6 };

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

 1 //首先實例化三個組件
 2 var widgetTitle = {
 3     id: wTitleId,
 4     type: 'title',
 5     //編輯部分
 6     data: {title: ''}
 7 };
 8 
 9 var widgetImg = {
10     id: wImgId,
11     type: 'img',
12     data: {src: '', alt: '', link: ''},
13 };
14 
15 var widgetVote = {
16     id: wVoteId,
17     type: 'vote',
18     data: {items: []}
19 };

而後將組件與活動關聯起來：

1 var activity_widget = {
2     activityId: actId,
3     widgets: [wTitleId, wImgId, wVoteId]
4 };

這裏再搭配起咱們的前端模板，能夠輕易的將一個活動的類容給展現出來：

在初步的使用中，我也認識到，關於不一樣組件類型編輯狀況應該不同，以前考慮的太簡單，只有字符串的場景，而投票這種組件是數組的狀況，後續還可能出現更加複雜的數據結構，顯然上述設計是不能徹底知足條件的。

修正設計

通過思考，我這裏產生了一個新的思路：

① widget_type中存取的是默認數據

② 咱們針對每個type會有一個特別的js控制器

這個思路來源於我作單頁應用，我一個頁面片會有一個頁面處理程序，因此一個類型的組件也應該有屬於他本身的控制器，由於這個活動組件會具備一個編輯和麪向用戶的展現，可能須要2個控制器，因而咱們來驗證這個想法。

有了這個想法後，感受一個頁面已經不能知足我了，開始了引入模塊化機制，這裏預計的是一個組件具備三種形態，也就是三種控制器：

① 後臺預覽模式

② 後臺編輯模式

③ 用戶瀏覽模式

事實上就是對一種數據結構的三種展現，不一樣的狀態有不一樣的表現形式，這裏是投票組件的簡單demo：

至此基本設計獲得了驗證，我以爲能夠持續在此展開了，至於組件刪除與保存數據庫就暫時不予實現。

結語

這裏花了一些時間整理工做中的需求，作簡單方案設計，誠然demo中的設計教簡陋，可是隨着一步步將初步構想變成實際項目，就會造成一些高大上的東西啦。

代碼地址：https://github.com/yexiaochai/module/tree/master/activity

demo地址：http://yexiaochai.github.io/module/activity/index.html