从 prop drilling 的泥潭到请求共享的天堂
亲爱的朋友，你有遇到过这样的场景吗？ 1. 希望严格遵循 React 哲学、维护单向数据流，于是状态提升提升再提升，提升到最后发现这个状态值似乎和当下组件没什么逻辑关联，只是它凑巧了，是共用这个状态值的那两个远房孙组件最近的共同父组件； 2. 写出一版提测了，产品经理指着页面说，“还是把这个统计数据移到上面那块展示吧，排版更好看一点，不难吧？”于是吭哧吭哧重写了组件树中所有被牵涉到的组件的 props，加班加点荣获了「效率低下」的美名，代码也被评价为「扩展性太差」； 3. 眼看着层层的 prop drilling 太反人类了，想想干脆祭出 useContext 吧，可转念又觉得大材小用、加剧耦合、倍感不值，只能背地里吐槽产品的设计毫无章法、后端的接口乱组数据，硬着头皮做他们的粘合剂； 4. 下定决心不能再被 best practice 捆绑了，放飞自我，就是天王老子来了也得是在直接使用到数据的组件里调用获取数据的接口，但是后端赶在天王老子之前来了，“你这一个页面里怎么能同时调用两次接口呢？会不会写前端啊？知不知道服务器压力有多大啊？” 前端已死，都去报名学习 AI 吧……呃，不是🚫 经人指点，在项目中封装了一个 Hook -- useSharedRequest，顾名思义，就是方便在多个组件间共享接口请求，但共享的不是接口返回的数据，而是这个请求的 promise。该 Hook 基于 ahooks 库的 useRequest 封装而来，写法完全一致，只需要在配置项中增加一个 shareKey 作为请求的唯一标识，就可以实现： 1. 在直接使用到数据的组件里调用获取数据的接口，保证组件逻辑内敛； 2. 同一页面多个组件调用相同接口时，只发送一次真实的网络请求，减轻后端压力； 3. 改造和维护成本极低，不管是接口替换还是组件层级变化，都不会牵扯到大面积修改。 基础用法如下图所示： 详细来讲， 1. 定义一个请求共享管理器类 RequestShareManager。 2. 在 RequestShareManager 中声明一个 Map<shareKey, Promise> 类型的私有属性 pendingRequests，用于存储正在进行中的请求。 3. 在 RequestShareManager 中实现...
