作为一枚前端，我想在我们的日常中，除了不断的积累各种语言框架外，我们更多的时候是给产品、业务提供切实、可行的解决方案，并最大程度上简化我们的后期维护工作。
本文以小程序端的两个场景为例，简述下我们在解决运营类数据的思路和方案。欢迎拍砖。
场景一：京东有礼小程序首页，动态实时更新页面数据
京东有礼小程序的首页，是为用户呈现的礼品卡列表。我们的需求是可以动态、实时更新礼品卡列表，比如春节期间推出一批拜年的卡面，而元宵节时更换为猜灯谜的卡面，平日再更换一批其他的卡面。这里我们称这些被动态实时更新的数据为运营类数据。
这其实是一个很简单的问题，即需求方在后台维护这些运营数据 => 后台提供数据接口 => 前端调用并渲染，就可以了。不过，当时后端没有维护“运营数据”的系统，在一周内完成系统并提供数据接口的方案基本被 pass 掉了。
当时适逢小程序推出 web-view 的解决方案，而在PC 和 M 端，需求方有通过运营活动平台搭建的活动链接，如果能够直接使用现有的活动链接，似乎也可以解决问题。不过 web-view 对业务域名做了限制，而我们搭建的活动页涉及到的域名、登录、领券等功能，未知风险不可控，一周内也未必能搞定，也放弃。
有趣的是，我们在考虑web-view方案的时候，发现运营活动平台可以提供数据接口！！活脱脱一个“配置系统”呀。很快我们确定了方案：在现有活动页的基础上，新增列表的数据结构，读取配置接口，渲染数据。
数据区域划分如下：
数据结构如下，数据结构如下，其中首焦、楼层通过groupName区分，首焦、楼层数据即是每个list的内容：
{
"info": [{
"groupId": "909",
"groupName": "2-1",
"list": [{
"desc": "我是描述呀",
"link": "//test.com/index?th=6fc56b4c50da",
"picurl": "//m.test.com/483808457/35289/e9f1ae9f/5a83d4ceN4f5a9dec.jpg",
"name": "我的名字",
"comment": ["sd88a87"]
}]
}]
}场景二：京东图书首页的多场景个性化实现。
京东图书小程序，承载着京东实体书，活跃在众多公众号的首页。比如我们的公众号首页，可以快速链接到京东图书的小程序。那么需求来了，我们每个公众号的受众群体存在着差异性，那我们怎么给用户提供精准的数据以便用户快速获取所需图书呢？
我们的方案就是为不同的公众号实现自己定制的京东图书小程序的首页，如下两张图中，分别是不同的公众号对应的不同京东图书的首页的活动页面，实现了多场景个性化的定制。
公众号一：
公众号二：
在收到该需求时，我们已经实现了通过 web-view 接入 H5 的方式，运营页面内容已经更加灵活。那如何实现这种差异性的展示呢？
有了场景一的启发，我们很快决定，借助活动平台，根据公众号的 appId 配置不同的 H5 url 链接。当数据约定完毕后，我们只需要在活动页根据数据，及当前小程序的 appId 进行匹配，待匹配成功后，将现在的 web-view 的 url 链接更新即可。
不过，我们在实现过程中也遇到了小程序的一些问题，即小程序只能获取特定场景下公众号的 appId，如下表所示：
小结
本文虽然以小程序端为出发点，但这些问题在日常中还是经常遇到的。这里把自己的感触归纳为几点：
* 运营类数据需要依托在可实时更新的系统上，即数据配置系统。如果您需要维护大量的运营页面或数据时，搭建您的配置系统。我们现在是临时借用的系统，如果业务有长期规划，可能也要搭建相应的配置系统。
* 关注你所在的生态圈，了解你身边的系统，是否可以快速的为你的产品提供有效的解决方案，并减少你未来的工作量。
* 小程序自身有些特异性，如何把它的特异性通用化，就需要我们的流程通用化，像图书的多场景个性化方案，已在多个小程序得到应用。而这些通用方案，也会逐步提炼成最新推出的“小程序插件”，直接对外开放。
