213 - 《如果我重新设计 Umi 01：组装式》

框架当如呼吸，轻巧无痕，用完就走。

1、相比组装式，与其对应的集中式大家应该更熟悉，Umi 和 Next.js 都是这种。这种方式下不给入口，按照约定把用户在 src/pages、src/app.ts 等文件拼成入口文件，写在临时目录里，然后交给 webpack 或 vite 编译。集中式的好处是收口，对哪里能改哪里不能改有明确定义，所以项目一致性会更好。但这个好处也是坏处，普通开发者会不知道项目是如何组织的，会给人感觉比较黑盒。

2、收了口子后，定制的需求是不会变的，应该如何处理？集中式通常会有插件体系，然后挖一些口子。比如 umi 的运行时插件有 render 和 rootContainer 等扩展口子让开发者扩展定制。除了黑盒，这种方式还有个不好的地方是类型提示不友好，比如框架没有办法知道插件里扩展了啥，修改了 render 的啥参数，或者通过 rootContainer 增加了啥 Provider，就没法做自动的类型提示。

3、组装式是啥？我理解是让框架更多向库的定位上靠，专注于提供功能，开放入口，让用户像搭积木一样搭出应用。这样子，每个部分就都是可替换可插拔的，比如不想要内置的约定式路由，自己写一个进去就好。对于开发者来说，对应用会有更多的掌控力，遇到问题绕不过大不了把这部分换掉就好。先看 client 端的例子，其中 mount 方式、Head、路由和约定式路由的组装方式均可替换，甚至可以完全不用 umi 提供的运行时能力。

目录。

+ src
  - entry-client.tsx