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的核心里面。虽然主要特点之一是文件即路由。控制了路由会有更多的可能。但是路由这个实现。在不同的框架里面有着不同的实现。并不能做到很通用。