基于Redux与依赖注入的多React应用整页共享方案咨询

结合你团队当前的技术栈（React、React Hooks、Redux、Saga）、共享页面组件层级复杂、各应用独立对接后端的实际情况，可按以下三种方案落地，可根据团队实际情况选型：

方案1：封装为私有npm包共享 #

• 核心思路：将待共享的整页连同依赖的所有层级子组件、Redux reducer、Saga监听逻辑全部抽离为独立的私有npm包，各业务应用安装后直接引入使用。
• 独立后端适配：共享包不耦合任何特定后端的请求逻辑，把所有需要调用后端的方法作为props暴露给宿主应用，各应用传入自己封装的请求实现即可，示例用法：

  // 宿主应用引入使用
  import SharedOrderPage from '@your-team/shared-order-page'
  // 传入当前应用自己的后端请求方法
  <SharedOrderPage 
    fetchOrderList={myAppApi.fetchOrderList}
    fetchOrderDetail={myAppApi.fetchOrderDetail}
  />
  

• 状态兼容处理：共享包单独导出独立的reducer和saga实例，各宿主应用将其注入到自身的Redux Store中即可，不会和应用原有状态产生冲突。
• 优势：改造成本最低，和现有技术栈完全兼容，共享逻辑可以统一迭代、发版更新。
• 劣势：需要各应用对齐React、Redux等核心依赖的大版本，否则可能出现依赖冲突。

方案2：微前端框架嵌入 #

• 核心思路：将待共享的页面单独拆分为一个独立的微应用，各业务应用通过微前端框架嵌入该微应用的对应路由即可使用。
• 独立后端适配：共享微应用不需要耦合后端实现，宿主应用嵌入时通过微前端框架的props传递后端域名、请求头或者封装好的请求实例，共享微应用直接调用传入的能力即可。
• 状态兼容处理：共享微应用可以单独维护自己的Redux Store，如果需要和宿主应用交互，通过微前端框架的全局状态通信能力做数据同步即可，不需要依赖宿主的Store实例。
• 优势：完全的依赖隔离，不需要对齐各应用的技术栈版本，适合各应用依赖版本差异较大的场景。
• 劣势：需要额外维护共享微应用的构建、部署逻辑，有少量的框架学习和适配成本。

方案3：封装为Web Component共享 #

• 核心思路：将共享页面连同所有依赖逻辑编译为标准Web Component，各应用直接通过自定义HTML标签引入使用。
• 独立后端适配：通过Web Component的自定义属性传入请求方法、配置参数，内部的Redux、Saga逻辑完全封装在组件内部，不会对外暴露。
• 优势：完全技术栈无关，不存在依赖冲突问题，后续就算团队引入其他技术栈的项目也可以直接复用。
• 劣势：Web Component和React的事件、复杂状态传递有一定的适配成本，开发调试难度比前两种方案高。

选型建议：如果团队各应用的React、Redux核心依赖版本差异不大，优先选择npm包方案，落地最快成本最低；如果版本差异较大优先选择微前端方案；如果后续有非React技术栈的复用需求，再考虑Web Component方案。

内容的提问来源于stack exchange，提问作者amos guata