感悟

前言事件源于一次跟CTO的交换，过后因为缓和而且间隔解决这些 bug 的工夫过得较长，所以过后答的一塌糊涂，所以就想着从新梳理下过后答复的问题，讲清楚问题的原由，做到功夫在平时，同时加深记忆。 总共说了两件事儿： 1. 翻页问题的异样。2. SSR 与 CSR 界线的辨别。总的起因产生这些问题有一个大的前提是因为，我的项目中了用到了服务端渲染（SSR），那么就须要去辨别 SSR 渲染与 CSR 渲染的状况。也因为之前没有解决过 SSR 的我的项目，所以在后期一些组件跟业务解决思维还是 CSR 的模式，导致了一系列的问题。 分页问题的异样BUG 形容我的项目曾经上线了很长一段时间了，忽然有用户反馈，浏览器回退按钮回退页面的时候路由曾经回退胜利，然而页面数据还是放弃的以后的数据。 BUG 剖析分页组件时对立封装的，那就去看看咋回事儿吧!先看代码 const clickPage = (page) => { if (callBack && typeof callBack === 'function') { // 这个办法是去请求分页的数据 callBack(page); } if (pathName.includes('?')) { history.push(`${pathName}&page=${page}`); } else { history.push(`${pathName}?page=${page}`); } };<Pagination.Itemhref={href}onClick={(e) => { e.preventDefault(); clickPage();}}>页码</Pagination.Item>下面给出一个页码的例子，Pagination.Item 会被渲染成 a 标签， 所以从这里就能确定产生这个问题的起因了，咱们先去拿了以后点击页面的数据，而后再去跳转了页面。 过后看到这就懵逼了，怎么会有这么奇葩的操作呢？分页不是应该先跳转页面，而后在页面内去监听页面的变动，在去申请数据这个流程么？为啥子要这样解决呢？ 这就要回到后面所说的大起因了，SSR 跟 CSR 加载场景须要辨别，为什么要去辨别？因为如果所有的模式都去走 SSR 的话，服务端的压力会很大，所以一些用户的点击操作比方翻页、排序等，这些操作就能够采纳 CSR 的模式，所以过后在写一些公共组件（分页，排序）时，就采纳了这种写法： 分页下面保留地址，有利于搜索引擎的收录跟 SEO，而后实际上采纳客户端跳转形式去扭转路由在跳转前去拿数据。这样能保障必定是 CSR 的形式渲染，不必去辨别 SSR 的影响。所以基于下面两种起因，采纳了这种形式去实现，其实这套逻辑如果不思考浏览器回退（低频操作）的形式，是齐全可能应用的，这也是一开始为什么没有发现这个bug的起因。BUG 解决既然 BUG 是由下面那两种‘长处’造成的,那就隔靴搔痒吧。 ...