dva 2.0

amodi 发布于 2017-03-27 dva 最后更新 2018-07-18 13:51 6 浏览

项目空点了,结合之前接收到的信息和自己的想法,列了 dva@2.0 的考虑如下。欢迎讨论。

  • 尽量兼容 dva 1.0,规则简单的 BreakChange,提供 CodeMod 一键升级
  • 独立的数据流方案,不强绑 React 或其他 view 库,不强绑 Router 库,但容易和现有绑定结合,#530
  • 内置合理的性能优化方案,比如 Reselect 的 memoization,不需要用户写额外的代码
  • 让 reducer 和 selector 更紧密地结合,并且让他们更容易写到一起。绑到一起,更容易写,更好组合
  • 更友好地进行错误提示,#436 #416
  • 更直观地处理 Code splitting
  • 更优雅地在 View 处理 Effect 的回调,#175
  • 更优雅的 HMR 方案,#469
  • 考虑 Model 的扩展和重用,比如:dva-model-extend
  • Code Style:重写 Plugin 实现,拆分模块等
已邀请:

qullam

赞同来自:

原生支持ts怎样?

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

nin

赞同来自:

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

baut

赞同来自:

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

jculpa

赞同来自:

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

uharum

赞同来自:

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

赞同插件化的方案,是否可以这样:

view - dva-core - [插件]

其中,对等于现在dva的部分是:

  • dva-core
  • dva-saga
  • router

后面两个是插件。

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

nsunt

赞同来自:

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

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

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

homnis

赞同来自:

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

baut

赞同来自:

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

kodit

赞同来自:

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

yeum

赞同来自:

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

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

aet

赞同来自:

可否支持 Immutable.js ?

fet

赞同来自:

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

lvel

赞同来自:

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

zcum

赞同来自:

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

xid

赞同来自:

其实 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 )还是有点麻烦

kex

赞同来自:

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

zin

赞同来自:

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

yvitae

赞同来自:

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

lmagni

赞同来自:

抽离 router 目的是什么

@nikogu

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

我觉得 dva 可以做得更多。

det

赞同来自:

@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 自己使用

tiste

赞同来自:

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 才能用,如果他是个插件,独立升级,就没这个问题了

fet

赞同来自:

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

sesse

赞同来自:

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

rtotam

赞同来自:

请问何时开始2.0?

lquia

赞同来自:

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

xminus

赞同来自:

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

ynulla

赞同来自:

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

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

enemo

赞同来自:

个人想到几点:

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

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

xnobis

赞同来自:

建议服务端可以服务端渲染,前后端一起写!

punde

赞同来自:

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

gut

赞同来自:

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

west

赞同来自:

@xufei
@sorrycc

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

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

lipsum

赞同来自:

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

jsed

赞同来自:

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

dsed

赞同来自:

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

qanimi

赞同来自:

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

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

yet

赞同来自:

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

mut

赞同来自:

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

mut

赞同来自:

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

tfugit

赞同来自:

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

aut_ut

赞同来自:

希望支持dva-cli支持stylus

xet

赞同来自:

支持ssr不。

cvelit

赞同来自:

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