在可视化建站项目中，基于架构的原因，所有组件像是乐高积木一样，并没有冗余在具体的页面里，通过运营配置的JSON去映射对应的组件，所以对于单个组件的各项逻辑完全是无法预知的，使用项目中广泛使用的baselist进行加载，ImprLogger进行曝光埋点的做法就完全不可取了，因为他们的初始化需要很多参数，而我们无法预知这些参数，也不能将这些参数转交给页面搭建人员去输入，因此我们使用了Intersection-Observer这一功能强大的api，用单一职责的模式设计了很多组件，每个组件保证一个功能，虽然功能单一，但是装载在业务组件里，就好像普通的业务组件多了左膀右臂，很轻松的增加了各种功能，而不是在传统开发中，使用功能强大复杂的baselist托管一切，通过复杂的配置项去驱动，通过生命周期调用不同方法来解决bug。
-
曝光埋点是指在商品或广告进入视口后，发送给后端这个商品的相关信息的一种行为，在大家的业务中非常常见，在我的开发体验中应该是遇到bug最多的点，大家或多或少会出现下列的情况 -
下拉加载是移动端场景的分页加载策略，后端接口设计成分页的模型，在滚动到页面底部时加载新的数据从而达到无限滚动 -
懒加载是移动web性能优化的常见手段，主要功能是在图片进入视口才进行加载，未加载之前显示占位图，图片加载完成后显示图片
先看看之前开发的痛点把！
-
使用古老的BaseList2时，在BaseList2的开发时，将埋点的逻辑直接冗余在列表中，后续的开发中，将曝光埋点的方法抽离出来，提供几个api，在BaseList2组件中进行调用，但是！！！并没有在原有BaseList2中将过去的方法删去，于是会遇到两个埋点冲突的情况，传入的props也有好多个，在文档匮乏的项目中简直难用！坑啊！
image.png
-
BaseList3是目前大家应用比较广泛受到好评的列表，主要是它功能比较完善，可以做很多逻辑，埋点封装的很完全，但是！！！他是采用继承式的写法，对一一个通用组件来讲继承式是api很不友好的，大家需要看源码才能知道这个组件都有什么方法，而且不能开箱即用，必须要继承列表组件写一个自己的列表组件才可以使用.可以看到下图，因为埋点方法抽出来了，比上面的强一点，可以直接调用曝光埋点的方法，但是还要写很多代码。
image.png
使用老代码该如何曝光埋点呢，戏称他为三部曲
- 在父组件初始化曝光器的单例
- 在列表组件对整块要曝光的区域做注册
- 每一个子组件都要把自己注册进步骤2中的曝光区块对象中去
在考虑项目能不能使用IScroll或者写成类似react-infinite这种回收移出视口的列表组件时，由于上述的埋点方法，只能停下脚步，而且有个坑！react组件渲染的声明周期是 父组件willmount - 子组件 willmount - 子组件 didmount - 父组件didmount 这样导致了步骤三会在没有SSR的静态页面中出错，因为父模块还没有didMount，子组件没办法注册到父模块中去。。。。。
遇到了这么多坑之后，我写了一个baselistV4，妄图通过api的封装解决了上面的问题，把复杂的逻辑都隐藏在列表中，但是页面数据加载和埋点逻辑太多了，也只能涵盖有限的情况
然后我遇到了Intersection-observer这个神奇的API，解决了上述问题
基本介绍
应用
- 曝光埋点
- 商品列表
- 懒加载
