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

发布于 2022年11月15日

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

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

内容预览已结束

此内容需要会员权限。请先登录以查看完整内容。