记一次单一原则的带来的感悟

需求越是简单，或者灵活越是要特别注意

代码中的，单一原则经常遇到，但是都没怎么好好记录过，这次刚好又遇到了，顺便写下，案例比较简单

背景

小程序有个菜单页面和首页（都是tabbar页面），产品希望可以根据首页的图片的跳转链接，让他跳转到菜单页面，并且根据携带的id参数，自动选中对应菜单项，如下图所示：

核心代码是都实现了，目前主要是实现：菜单页面根据query里的id参数，实现菜单项高亮

前期思考

首先先思考输入环节，这个链接格式是什么，应该有什么参数，根据产品要求，那么这个链接就需要：[菜单路径] [id参数]，比如：

链接格式：pages/index/index?id=1

然后思考，页面该怎么做，很明显，在进入页面时就去获取query参数，根据query参数里的id，变更选中菜单项的id，从而实现对应菜单项高亮

思考改进

由于小程序tabar页面无法携带参数，所以无法在onLoad环节获取query参数

那么我的做法就是，选择storage，缓存下这个query

具体过程更改为

链接携带cache参数，进行标识：pages/index/index?id=1&cache=1
跳转时判断链接是否有cache参数，缓存数据
菜单页面获取缓存数据，进行赋值

重点

这里主要讲讲第2步缓存query的逻辑，因为我设计的第2步有问题，这样就导致第3步有问题

旧版设计

以下核心代码

js 复制代码

const page = 'menu'
const query = getQuery()
if (query.cache) {
    const pageStorage = wx.getStorageSync(page) || {};
    wx.setStorageSync(page, { ...pageStorage, cacheQuery: query });
}

这部分设计，其实是把每个页面名（page），看成一个缓存对象，里面有query缓存，也有页面里的缓存

这其实不太对，因为我们只需要关心页面里的query缓存数据即可，而不是关心页面里其他的缓存数据

这步错了，就会导致第三步也会错误，所以需要优化

新版设计

js 复制代码

if (query.cache) {
  const queryCache = wx.getStorageSync('queryCache') || {}; // 所有query的cache集合,同步获取
  queryCache[page] = query; // 对当前page进行赋值query
  wx.setStorageSync('queryCache', queryCache); // 同步设置query缓存
}

新版设计思路，定义一个大的query缓存对象，key为queryCache，里面数据为每个页面的query缓存

page为页面名，比如index，通过page名进行隔离其他页面的query缓存数据

这样就只需要考虑链接上带来的query缓存，而不用考虑其他地方注入的缓存，职责更加清晰

总结

核心就是这些，因为前后设计设计思路不一致，实现起来就不一样，一个是缓存页面里的数据，一个只缓存链接上的参数

案例还是比较简单，就是个人设计有点小问题