前言

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

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

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

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

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

② 有規律類模組化活動

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

③ 無規律定製化活動

這裡活動基本我們沒法辦法了，他可能做成一個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中的設計教簡陋，但是隨著一步步將初步構想變成實際專案，就會形成一些高大上的東西啦。

程式碼地址：

demo地址：