来来，一块儿设计一个简单的活动发布系统

前言

前段时间我写了一篇博客：小公司的前端应该怎么作？，其中核心的几个观点之一就是要把重复工做给干掉！

而咱们平常工做中有一类需求名曰活动，这些活动就像脏水同样不停的向咱们涌来，并且要的又急，这个时候有些团队就会疲于奔命的去让前端作页面而后走发布流程，若是你的公司是这样，业务发展后再多几个前端也不够。

我这里说的活动大概分为四类：

① 描述性活动（或者说简单类文案）

这种直接作一个相似新闻发布系统的东西便可，这里不予讨论。

② 有规律类模块化活动

这里活动的场景比较多，通常是有文字，有图片，有一些简单的商品操做，甚至有投票统计。

③ 无规律定制化活动

这里活动基本咱们无法办法了，他可能作成一个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