一次基于Taro的曝光逻辑踩坑记录

1,188 阅读2分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第1天,点击查看活动详情

事件起因

由于需求迭代,在详情页增加了热门/相似职位推荐列表,为了进一步确认推荐列表对职位的效果提升,增加曝光埋点统计处理,一切从数据出发。

实现方案

由于之前做过H5端的埋点上报,自然而然想到了通过IntersectionObserver进行监听的方式来实现。至于老旧的滚动监听就不再赘述了,想必实在没办法的情况下才会去考虑[旺柴]。

IntersectionObserver

首先我们需要创建一个 IntersectionObserver Taro.createIntersectionObserver(Object component, Object options),IntersectionObserver 一共有四个方法

  • IntersectionObserver.relativeTo 使用选择器指定一个节点,作为参照区域之一。
  • IntersectionObserver.relativeToViewport(Object margins) 指定页面显示区域作为参照区域之一
  • IntersectionObserver.observeCallback callback) 指定目标节点并开始监听相交状态变化情况
  • IntersectionObserver.disconnect() 停止监听。回调函数将不再触发

开发实现

通过在JobItem组件中进行监听来实现每个职位曝光逻辑,简要代码如下:

function JobItem({
  item = {},
  exposure = () => {}, // 曝光处理
}) {
  const initObserver = () => {
    observe = Taro.createIntersectionObserver(this);
    observe
      .relativeToViewport({ bottom: -100, top: -100 })
      .observe('#Item_' + infoID, res => {
      if (res.intersectionRatio > 0) {
        exposure();
      }
    });
  };
  
  useEffect(() => {
    let timer = -1;
    timer = setTimeout(() => {
      initObserver();
    }, 10);
    
    return () => {
      clearTimeout(timer);
      observe && observe.disconnect();
    };
  }, [item]);
  
  return (
    <View id={`Item_${infoID}`}>
      ……
    </View>
  );
}

逻辑开发完之后在详情页观察推荐列表滚动曝光功能正常,心里美滋滋的想“Nice!”。

踩坑开始

由于推荐列表职位组件是复用首页列表的职位组件,所以想着给首页也增加上曝光逻辑,一次性补充完整。按照详情页逻辑追加相关处理后,简单看了下曝光触发没有问题,以为就这样顺利完工了。

由于曝光上报需要将每个职位在列表中的位置进行数据上报,所以额外留心了下位置数据是否正确,结果发现,首页中每个分页更新后,新分页的头部几个职位居然没有上报,出现了漏报的现象。

瞒报漏报是要承担责任的!!! 😈😈😈

分析问题

通过和详情页对比,发现可能是由于首页组件层级引起的。现有的首页由于之前做过性能优化,结合虚拟列表的思想,组件层级是按照List组件-Page组件-Item组件这个结构来设计的。先简单介绍下这个优化方案:

优化方案

通过对已有的长列表方案进行分析对比获知:

由于当时上述两个方案都和我们小程序的实际情况不是很贴合,所以自行结合虚拟列表的原理,设计了现有的优化方案:

这样就比常规方案里面把缓冲区外的item置成空的方案进一步减少了Dom结构。在这个方案里面,每个Page组件增加了IntersectionObserver监听,来更新当前分页与缓冲分页的页面编码。

找到原因

通过对组件Page层级组件的分析,怀疑是Page组件的监听事件优先级高于Item组件的监听事件,从而导致在更新分页时,新的分页的头部Item被分页的事件拦截了。

探寻解决方案

通过对IntersectionObserver相关资料的查找以及结合过往H5中的使用方法可以知道,其使用场景其实可以划分为两种:

  • 组件内部:此时监听的是组件自身,在调用createIntersectionObserver进行创建是传入的第一个参数是自定义组件的this;
  • 小程序页面级(Page):此时可以监听一类组件元素,通过给需要监听的组件增加统一的类来实现监听。

那这样我们是不是可以给上面的Page组件和Item组件添加相同的监听类,来统一监听,就不会有事件优先级的问题了啊,说干就干,改造开始。

Round One

将Page组件和Item组件中的监听逻辑全部去掉,然后同步增加相关的class ObserveItem。在首页的页面文件中增加监听方法:

initObserver = () => {
  setTimeout(() => {
    // this.$instance = getCurrentInstance()
    this._observer = Taro.createIntersectionObserver(this.$instance.page, {
      observeAll: true
    });
    
    this._observer
      .relativeToViewport({ bottom: 0, top: 0 })
      .observe('.ObserveItem', res => {
      console.log('ObserveItem res', res)
    });
  }, 30);
};

其中需要注意的是,在Taro开发小程序时,我们可以通过getCurrentInstance()方法来获取页面的路由、实例等数据。通过查阅小程序的官方文档得知,在监听回调里面时可以返回一些有用的数据信息的:

这样我们就可以通过在监听组件上面通过data-* 的方式来保留一些数据用于进行区分和使用了。

理想很丰满,现实很骨感

监听发现,在Taro框架下,监听回调的参数里面dataset就是个{},明明小程序官方的例子是有的,结果,Taro居然没有!!!

好的消息是,事件优先级的问题解决了😂

Round Two

既然事件优先级这个核心问题解决了,那其他的我们只能绕绕路来实现了。通过对回调方法的数据分析得知,组件元素的id是可以获取到的。通过查阅github相关issue得知,可以通过ref获取到组件元素的dataset数据。

那我们只需要每个组件id对应上它的ref就可以在曝光的时候拿到我们需要的数据了。所以在每个组件的Hooks中追加了收集ref的方法调用

// Page组件
const element = useRef(null)
useEffect(() => {
  collectRefs('page', 'JobPage_' + page, element);
}, [...]);
    
// Item组件
const element = useRef(null)
useEffect(() => {
  collectRefs('item', 'JobItem_' + id, element);
}, [...]);
    
// 页面文件中
collectRefs = (type, id, ref) => {
  this[`${type}RefList`][id] = ref;
};

这样通过维护两个对象来存储每个监听元素对应的ref,在曝光触发的回调中进行处理

this._observer
  .relativeToViewport({ bottom: 0, top: 0 })
  .observe('.ObserveItem', res => {
  const id = res.id;
  // 通过id中包含的专有前缀判定是哪个级别的组件,然后分别进行对应处理逻辑
  if (id.indexOf('JobPage') >= 0) {
    // 分页更新逻辑
  } else if (id.indexOf('JobItem') >= 0) {
    // 曝光处理
    this.exposure(
      this.itemRefList[id].current.dataset.item,
      res.intersectionRatio
    );
  }
});

踩坑回顾

其实这次需求处理是一个很常规的逻辑,只不过遇到了多级同类事件影响,以及框架封装能力和小程序官方不一致的情况,导致处理起来做了很多“迂回”处理。特此对这次问题的分析过程进行了本次汇总,希望能够帮助遇到同样问题的同学。如果您有更好的解决方案,也请留言告知,不胜感激!