Are you thinking of taking the React part of the Umi as a plugin?
xiaohuoni opened this issue · comments
Prepare for subsequent Umi support for other frameworks or without frames
有类似想法,但不一定是插件的形式,具体方式待定。
下午正好有在考虑 umi@2 的部分,umi@1 由于业务上需求,其实混杂了很多业务元素的东西,比如为了云凤蝶发布处理的 route base,为了 h5 离线包处理的本地 file:// 打开的运行模式,以及 antd、hd 方案等等很多功能,这些的东西糅合在一起让 umi 并不那么纯粹。我希望 umi@2 能更纯粹些,找到属于他的核心功能,然后其他功能均通过插件的方式存在。
那么哪些是核心功能?我觉得是:
- 基于约定、配置的完整的路由处理方案
- 完整的开发生命周期,路由 -> JS -> HTML -> 部署
- 基于开发生命周期的插件机制
所以,预计会提一个 umi-core 出来,理想情况是仅包含对于核心功能的处理,甚至都不包含 webpack 的处理,在框架上适配 react、vue、小程序、react-native 等,工具层可以适配 rollu
p、parcel 等。
我个人觉得如何处理好开箱即用和高度可配置性,是一个蛮关键的问题。
零点几的版本是我觉得完成的最好的开箱即用版本,功能也没有少,配置文件却很简单,API文档也很简单清晰。只要理解了文件即路由的**,看一下demo就能随意编写,甚至不懂什么是dva什么是react,就能上手做项目。
后面随着业务的发展,感觉现在到了1.3的版本,配置文件越来越繁琐,感觉光环境变量就有一大堆。而且,感觉文档也跟不上。(我知道的应该有16个,文档中是15个,少了HARD_SOURCE。可能遗漏的还有其他的。)假如我现在才开始使用umi的话,那一堆插件(umi-plugin-*),都有些什么配置,我就不是很清楚。而且插件到底算不算umi的内容,也是一个值得考虑的问题。
文档是个大问题,我估计得闭关 10 天专门写文档!(据说 egg 的文档是这么搞出来的)
我觉得路由最好不要算在umi的核心里面。虽然主要特点之一是文件即路由。控制了路由会有更多的可能。但是路由这个实现。在不同的框架里面有着不同的实现。并不能做到很通用。