<p>dva 2.0</p>

原生支持ts怎样？

unmodel的时候是否考虑支持传一个reducer来销毁用不到的state数据？https://github.com/dvajs/dva/issues/769

dva-cli 改名为 roadhog 如何？免得概念混淆。

个人不赞成原生支持ts，框架应该尽量与其他不相关的技术栈解绑，保持纯粹，宁可少做，就比如 unmount model的state问题用现有的api也可以做到吧，还有react-router看计划是要拆分成独立的组件比如react-router-dva吧，我后面也可以写一个react-navigation-dva给rn用

还有优化方案也都可以以插件的形式提供支持，比如dva.use(reselect)，就像express 的中间件机制，只内置了static插件，其他的都是分开支持的，甚至saga都可以是可选的

@nihgwu 我表达错了，意思是像antd一样，自身用ts写，不限制使用者，这样有个好处是不必一直手动同步发布类型文件。

赞同插件化的方案，是否可以这样：

view - dva-core - [插件]

其中，对等于现在dva的部分是：

• dva-core
• dva-saga
• router

后面两个是插件。

dva是否可以定位成：专注于表达视图和数据关系的库？视图是哪种框架，数据来源是什么方式，都搞成可替换的？然后，为了跟1.0的平滑升级，把dva定义成dva-core和saga的默认组合？

不知道底层的封装是否方便支持实例类型的 dispatch type ？

dispatch({
  type: model => model.product.loadAll,
})

记 string 也是比较麻烦的，而且经常忘记写 namespace，要是有下拉提示就好了，而且重构起来也方便～

不知道可不可以 为 state 中的所有数据 默认提供一个 set 的 reducers
在大多数场景下， 我都需要手动的去写一个 reducers ， 可能只是为一个 字段赋值，所以如果能够默认按照约定 为我提供现成的 单字段的 set 方法那是相当好的

reducers 能不能实现成树形的，像现在 ns 分割强制的把逻辑都打平了，一个 model 对应的实际上是个 reducer 的 root，下面挂的 reducer 太多了

@xufei 我觉得 saga 应该在 core 里，离了 saga 就不是现在的 dva 了，从实现角度好像也很难把 saga 抽成插件。

@xufei 不好意思，我后来也感觉你应该指的是用 ts 来写，不过我觉得也没必要吧，毕竟 dva 的接口也简单，不能因为类型文件而用 ts 重写

@sorrycc 分离 saga 我也是举个例子，确实 dva 的核心就是 redux + redux-saga，不过从实现角度，我们可以通过 callback hook 的方式来分离成插件吧

可否支持 Immutable.js ？

赞成支持Immutable.js，Immutable.js 对性能优化作用比较突出

roadhog 打包太消耗性能，看看能不能优化下，能的话就尽量优化下，现在在服务器构建项目前都得把其他的容器停了，不然服务器必定卡死。

不赞成使用Immutable.js，结合lodash和spread操作也能很好的实现immutable效果。而lodash基本内置。

其实 dva 1.x 的开发体验已经很不错了，类似于是否支持 Immutable.js ，拆分 saga，原生支持 ts，感觉都没什么必要，都属于开发者自我爱好，对实际开发效率和体验没什么大的影响。

个人有 4 个点是需要 dva 2.x 考虑的：

1. service 层的优化，是否能抽到 model 里面，并且统一封装，基本上不要关心 request，然后默认提供网络异常处理等，现在基本上都需要自己来写 request.js；

2. 就是 view 层 effect 回调的问题，将业务逻辑完全抽离成 model 数据放在 effect 里面处理是不现实的（太过繁琐），所以这一块是需要有个更优雅的方案。

3. 就是 dva 周边社区的建设，目前脚手架的类型已经样例还是比较丰富的，但是还是需要更多的建设，感觉要达到 angular 或者 react 社区本身的资源水平才算是目的吧。

4. 构建工具的强化，性能、功能等（目前 mock ）还是有点麻烦

对于我，最关心的是 router 的分离，我觉得 dva 只要包括 redux + redux-saga 就好了。redux 社区都是提倡尽量少做，所以 1.x 的打包 react-router 以及 fetch 感觉都没有必要，以及上面有人提到的 Immutable 这个属于开发者的喜好，作为维护者，不应该具有倾向性，对于开发者的喜好，可以通过插件的形式支持，还有 service 层的问题，如果有必要可以自己写 plugin，而不应该包含在 dva-core 里面

@nihgwu 抽离 router 目的是什么，dva 应该是需要合，而不是分，最终的开发体验应该是一整套方便的解决方案，并且在扩展性和易用性上达到平衡，如果要『尽量少做』，那直接用 redux 好了，我反而觉得框架应该『尽量多做』。

@nikogu 做太多了，新手也会茫然，不知道原理是什么。不过doc详尽的话，也是可以的

抽离 router 目的是什么

@nikogu

目前 dva 的应用范围有点窄，强绑了 react 社区，自然也包括 view，还强绑了 react-router。但用下来发现有些地方不需要 router，比如无线多页应用；有些地方 react-router 不适用，比如 react-native；有些地方不需要 react，比如 node、electron 和小程序。

我觉得 dva 可以做得更多。

@nikogu 抽离 router 是因为我们可以有不同的 router，比如在RN里我可以用 react-navigation，还有 react-navigation 也支持 web，这种完全可以通过 plugin 来支持，实现更好的自定义

我理解的 dva 是以一种新的形式组织 redux 和 saga 代码和逻辑，而不是提供一整套的 web 开发框架，就比如 express，也是利用 node 现有的 api，提供了 web server 的基础功能，至于你如何处理 body、cookie，选择什么模板引擎都是可以通过中间件自定义的

如果你喜欢完整的解决方案，完全可以实现一个 dva-ant = dva-core + dva-plugins 自己使用

dva 的合应该是 redux 和 saga 的合，因为这两个是数据状态流的核心，其他的都只能算是建立在数据之上的周边，都可以以插件或者其他方式提供支持，我们可以比较下 express 和 Django，典型的少做与多做的区别，有人喜欢大而全，但 js 社区更推崇小而美吧

至于直接用 redux，我用 dva 的主要原因就是因为 dva 能简化 redux 的代码结构和逻辑，提高生产效率，这也是 dva 建立在 redux 之上的核心吧

如果我们一味的做多，会让 dva 的应用场景越来越狭窄，就比如 react-router 在 RN 里用不了（v4已经支持但是很初级），RN 里也自带了 fetch，还有强绑其他库，也会造成升级依赖问题，还是 react-router，V4 支持了 RN，但是 dva 里的还是 V2，我们必须等 dva 升级了 react-router 才能用，如果他是个插件，独立升级，就没这个问题了

我前面提dva-core的意思就是，把小核心当作dva-core，这个里面把router之类的拿出去，然后搞几个默认整合方案，比如公司内部统一版本的，面向中后台，面向H5，面向小程序，面向服务端渲染，等等

2点：
1、实际开发， model 里面 实现业务逻辑，文件太大，另外一个跟 service 关系是什么？ service 或者 request 之类的可以内置
2、react-router 改为系统自带插件，或者什么的，目的就解脱依赖

请问何时开始2.0？

可插拔的ssr解决方案，抽象对router的管理，server端可以接管首次路由请求，利用共享的dva()初始化状态树，感觉随着dva不断升级，服务端渲染对新特性应用偏弱。

TypeScript和RN。希望能得到更好的支持

又想到一个，提供一个默认的 namespace

我在使用 dva 的过程中，总是会有不需要任何前缀的 reducer 的情况，而 dva 目前的实现是必须提供 namespace，所以我有个提议，如果 namespace 为 default （或者 global 、*）的时候，我们就认为这个 model下面的 reducers 都是没有前缀的

个人想到几点：

• 不依赖于 redux-saga，这样可以很容易的添加一些功能（如 async/await 支持）
• 拆成多个小模块（比如 store 单独一个，router 单独一个）
• 支持 nested model

我们最近仿照 vuex 基于 redux 写了一个不知道是否有参考意义：https://github.com/d-band/yax

建议服务端可以服务端渲染，前后端一起写！

可以设定 routes 目录的名字吗？比如用 container
其实更想按功能划分目录，把 model, service, container 放一起，不然几个目录跳转很破坏心流。为了知道 sublime 上方 tab 开的 user.js 到底是干嘛，我都已经这么取名了：user.jsx, user.model.js, user.service.js。放一起可以 user/model.js, service.js, container.js

@zheeeng 这样的目录组织现在就支持吧，dva 对于目录组织没有限制的。

@xufei
@sorrycc

unmodel的时候是否考虑支持传一个reducer来销毁用不到的state数据？

手动控制太麻烦了 ， 建议直接实现一套GC

请升级一下 pathToRegexp，它的 parse, compile 的方法不能直接使用

约定优于配置，减少和其他工程或技术栈的耦合。

effects业务太重了，model-extend这种思想挺好的

@nihgwu 个人同意“ dva 的核心就是 redux + redux-saga”，实际项目开发经验来看 redux 很好，但是开发过程中 action、reducer、select编写太麻烦。dva model 的约定方式能够大大的减少模板性编码。

@sorrycc 请问 dva 2.0 有最新的发布计划不？

强烈希望 dva-cli 可以选择生成 TypeScript 的 boilerplate

dva-core已经可以用于微信小程序

@yautah 试过了？试过了可以分享下方案。

感觉dva-core只要提供redux数据流的再次封装就行了，其他的是不是可以用插件形式提供，或者让用户自选会好些，比如打包和路由方案

希望支持dva-cli支持stylus

支持ssr不。

HRM需要怎么配置，API的写法比较少