是否应将React项目中的复杂组件抽离至独立组件库维护？

跨项目复用绝对不是搭建独立组件库、抽离组件的唯一理由，你提到的提升可测试性、简化主项目复杂度完全是合理的考量，但你团队提出的额外维护负担也确实是实际存在的坑——绝大多数新手在这件事上踩坑，都是把「组件解耦拆分」和「拆成独立发版、独立仓库维护的npm组件库」划上了等号，这俩根本不是一回事。

你团队反对的从来不是「拆分复杂组件」，而是反对「为了追求组件库的形式，平白增加无意义的维护成本」：

• 完全独立维护、单独发版的组件库，确实有非常高的固定成本：你要单独维护webpack/rollup构建配置、生成TS类型声明、管理版本号、处理和主项目的React/第三方依赖版本对齐、调试时要配npm link或者本地软链、还要单独写文档、维护变更日志。如果确定组件完全没有跨项目复用的可能，这部分成本100%是额外支出，没有任何直接收益。
• 但反过来，拆分复杂组件的收益本来就不止跨项目复用一项，你想到的两点完全站得住脚，甚至还有更多被忽略的价值：
  • 强制划清代码边界：把复杂组件从混杂的业务上下文里抽离的过程，会逼着你明确区分「组件自身的通用逻辑」和「和业务强绑定的特殊逻辑」，从机制上避免组件随便引用全局状态、耦合业务接口、写死业务逻辑的问题，从根源上降低后续改代码牵一发动全身的概率。
  • 实打实提升测试效率：和业务解耦的组件不需要启动整个主项目、不需要mock十几层业务依赖就能跑单测，用例写起来快、跑起来稳，出问题也能快速定位，不会出现单测跑一半因为某个没mock的全局业务变量直接报错的无效调试。
  • 降低整个项目的认知负担：组件按层级独立存放后，新入职的开发不需要在层层嵌套的业务文件夹里翻找组件，也不会因为改业务代码不小心动了公共组件导致其他页面出bug。

完全没必要一上来就搞独立仓库、独立发版的重型组件库，你可以用成本极低的方式拿到组件拆分的全部收益：

• 先在当前项目内做域级别的组件隔离：不管是用Monorepo建内部packages/components模块，还是直接在src目录下建独立的components文件夹、配好@project/components的路径别名都可以，把要抽离的复杂组件先挪到这个目录下。
• 给这个独立目录加单独的规则约束：比如禁止这个目录下的组件直接引用上层业务目录的代码，所有业务依赖必须通过props传入；给这个目录单独配单测脚本，要求组件覆盖率达到标准才能合入。
• 等这套内部隔离的机制跑顺了，后续真的出现跨项目复用需求的时候，再把整个目录平移出去做独立发版的组件库，到时候花在构建、版本管理上的成本才是划算的。

别为了「用上组件库」的形式感做拆分，组件拆分的核心目的是降低维护成本，只要边界划得够清楚，哪怕组件全放在主项目仓库里，也能拿到解耦、易测试、复杂度降低的全部收益，没必要一开始就上最重的方案。

内容的提问来源于stack exchange，提问作者Simple Fellow