一个不优雅的React埋点方案

前言：

首先感谢产品各种“合理不合理”的埋点需求，让我按奈住内心的暴动之后不得不提出这个不够优雅的埋点解决方案。

说其不够优雅的原因在于初衷是设想在react-dom上实现原生的参数事件，但经过一番调研后还是浅尝辄止的选择了这个替代方案，用组件化的思维来解决问题。

描述：

依据埋点的三大类技术方案来划分(代码埋点，可视化埋点，无埋点)，react-tag-component隶属于“代码埋点”，它对于开发的意义主要有以下几点：

减少对代码的侵入性：不允许任何埋点事件出现在业务代码中。

统一埋点标准：方便团队对于项目的维护，同时便于迅速定位埋点位置。

管理埋点数据：埋点静态数据储存在统一仓库中，随时可以增添。

使用灵活：可以自由注入打埋点的相关事件。

快速应对各类埋点需求：持续集成众多埋点方式，解决各类需求，加快项目的开发速度。 根据现有需求，已集成的埋点方式有：react组件生命周期中埋点，click事件中埋点，上滑时展现埋点，左滑动时展现埋点。

如果在我们的react项目中处处充斥着埋点事件，或许我们要因为埋点而将无状态组件提升为状态组件、在没有click事件的Dom上绑定onClick，或许我们也要为埋点写出更多的页面交互。那么我们不妨做出更多的尝试，将问题汇总，使其可以统一解决。

核心：

该方案的核心由三部分组成，首先是建立数据存储，其次是自定义方法注入，最后是组件上参数挂载。

在需求开发中，埋点数据可以分为两类。第一类是静态数据，第二类是动态数据。静态数据是一开始就确定好，不会存在修改或追加的可能，而动态数据是在静态数据的基础上依赖于ajax请求或者页面相应节点参数的绑定。

建立数据存储是对静态数据的统一管理，而动态的数据则是在组件上注入，二者的处理方法由注入事件决定。在整个组件中，必要的参数只有type，他决定了我们埋点的输出环境，而当其为滑动展现埋点时，pid也成选填项，其为展现时相对的祖先节点id，具体使用请参考GitHub文档。以下为整个方案的主要流程：

集成：

该项目也是我对前端项目工程化的一次完整尝试，在github上我们能够看到以下的这些徽章。

其中包含了项目持续化集成过程中的构建结果以及代码测试覆盖率，涉及到的具体技术内容有：

持续化集成：travis-ci，

测试框架：mocha，

断言库：assert(Node原生)，

测试覆盖率：istanbul、coveralls

最后：

目前项目并没有应用在太多的实战中，代码本身和功能上都还需要不断的完善。我会在日后开发中涉及到的埋点的地方全部使用该方案，从而完善更多的功能，并在之前的基础上使项目更加工程化和自动化。

再安利一个58内部媒介上传平台，现已支持图片、视频上传功能。地址：http://hrgnode.58.com/zcm/mediaupload

Github地址:https://github.com/ZBcoder/react-tag-component