讨论：dva-cli boilerplate structure

[sorrycc]

大家看下脚手架的目录应该如何组织? 以下是初始方案。

.
├── /mock/
├── /src/
│ ├── /components/       # React components
│ ├── /models/           # model 信息
│ ├── /routes/           # 路由 Component
│ ├── /services/         # 处理和服务器的交互
│ ├── index.html
│ ├── index.js           # 应用入口
│ ├── index.less
│ └── router.js          # 路由配置
├── package.json
├── proxy.config.js
└── webpack.config.js

详见：https://github.com/dvajs/dva-cli/tree/master/boilerplates/app

@ChrisFan @yiminghe @nikogu @afc163

[nikogu]

如果只是一个模板的话，我觉得还是全点好，多了删起来简单，但是少了加起来就不太好加＝。-，我的建议：

• mock 数据mock的接口文件
• src 项目源码目录
  • components 项目组件，一般为Stateless Components(Presentation Components)
  • containers 业务容器，一般为Smart Components，跟数据相关联
  • layouts 业务通用布局
  • routes 路由配置
  • services 项目数据接口
  • entries 项目入口文件
  • [selector] 可选，项目统一缓存数据
  • [constants] 可选，项目统一常量
• package.json 项目信息
• proxy.config.js 数据mock配置信息
• webpack.config.js

[sorrycc]

有几点和之前不同的是：

1. 移除 entries 目录，直接把 index.js 放在外层，因为默认是单页应用
2. router.js 从 /routes/ 里提出来，/routes/ 里只放 Route Component，不混在一起，参考 emberjs

[yiminghe]

哦，原来的 antd-init 的 demo 照这个结构有了么

[sorrycc]

@yiminghe 你是指 antd-init 的 demo 也要有这个结构? 那不是只有一个 index.js 文件的极简模式吗?

[ChrisFan]

看了下没什么问题。只有一点，我们要不要推荐 containers 这种写法？

[nikogu]

我个人是觉得route component有点歧义，containers虽然好像格调不高，但是表意还是挺清楚的（对于大型应用），entries和routes的设计我个人觉得可以算是给大型设计留入口吧，虽然dva的api和设计思路跟emberjs差不多，但是可能dva以后会更多的用在中后台大型应用中，该留的口子可以先留着 😄

[ChrisFan]

routes 目录我们目前系统中是用来放 403 404 之类的 这种应该每个系统都有吧
On Mon, Jul 25, 2016 at 10:11 PM niko notifications@github.com wrote:

我个人是觉得route
component有点歧义，containers虽然好像格调不高，但是表意还是挺清楚的（对于大型应用），entries和routes的设计我个人觉得可以算是给大型设计留入口吧，虽然dva的api和设计思路跟emberjs差不多，但是可能dva以后会更多的用在中后台大型应用中，该留的口子可以先留着
😄

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#21 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA2yaEP4a7dOBvvZH-V6b0xLOyEOjBm-ks5qZMQtgaJpZM4JT_1b
.

[sorrycc]

感谢讨论，说下我的理解。

---

routes vs. containers

routes 用于存放 router 定义的 component，和 router 对应，可能是 container，也可能是 component。单独启一个 routes 目录存放还有个原因是考虑后续的 fine generator 功能，比如 dva generate route users，生成 routes/Users.jsx 会比 containers/Users.jsx 好理解。

另外，外层有一个 router.js，用于配置路由信息。(需注意 router 和 route 的区别)

要不要 containers 文件夹

即：要不要推荐 container 这种写法。先不推荐吧，1 是 containers 容易和 routes 混淆，2 是为了减少概念。components 里同时包含 container 和 component，f8app 也是如此。

要不要 layouts 文件夹

我之前也有配 layouts 文件夹的，昨天沉鱼说 layouts 其实也是 components，为何要单独分出来呢? 我想想也是如此，所以就把 layouts 删掉了，放在 components 里名字带上 layout 后缀吧。

selectors 和 constants 文件夹

这个应该放在 model 下组织吧。

entries 文件夹

这个其实是看我们的应用大部分是什么类型? 多页面还是单页面。我觉得 80% 应该是单页应用，所以把 index.js 提出来，同时简化了 entries 的概念。多页应用通过文档或者 addon 的方式提供吧。另外以我之前做过的多页(子应用)应用来看，组织其实挺复杂的，可能需要每个页面(子应用)都有自己的 models、components、services，只是有一个 entries 目录并不一定能解决问题，感觉通过文档或其他方式提供建议会更好。

[yiminghe]

是 antd-init redux 那个 demo

[ChrisFan]

原来 routes 是指 route 对应的 Component，那这样也没问题，从 angular 背景过来很习惯每个路由有一个对应的 template & controller，有点类似这种概念。

[sorrycc]

@yiminghe antd-init 保留最简的 demo 版本，然后引导到 dva-cli 。

[LeuisKen]

其实我还是比较赞同 @nikogu 给出的结构的。

我之前的习惯是container + component（用了connect就是container，没用connect就是component），route仅仅包含Router里面的内容，也就是路由结构。所以我还是希望保留container的。

对是否保留entry持中立态度，偏向保留，毕竟对于单页面应用，多一个entry并不会有什么影响。

constants 这个文件夹以前用过但是根本没用起来，不建议。

[afc163]

layouts 虽然也是一个组件，但是从工程意义来讲，稳定的布局组件入口让项目比较容易上手。否则可能我都不知道 layouts 是放到 components 下的。

另外还有 tests（测试）、static（静态文件）、styles（全局样式）、utils（通用工具方法） 这些目录也可以考虑下。

[afc163]

另外 mock 数据现在都放在 proxy.config.js 这一个文件中？搞一个 mock 目录如何？

[ChrisFan]

tests 目录 ＋1

@afc163 mock 目录在外面，proxy.config.js 可以配置是走 mock 还是 redirect 到其他地址

[sorrycc]

改动：

1. 现在有 mock 目录的，在外层
2. tests 加上，基于 atool-test-mocha 实现
3. utils 也加上，把 services/xFetch 放到这里，这样能让 services 更纯粹
4. index.less 就是全局样式，换成 style.less? 感觉全局样式不需要一个文件夹吧

其他：

1. layouts 和 static 先不加，文件夹已经好多了。。翻了下其他 boilerplate 基本上也没有提供这类的
2. containers 我还是坚持和 components 放一起，之前确实是分开的，但发现为了 connect 提取一个和 components 下的同名文件出来很蛋疼，尤其是 containers 下的文件多了之后。感觉是为了拆而拆，我更偏向实用主义

[nikogu]

我的建议还是分成 containers 和 components ，理由如下：

首先先引入一篇文章 Presentational and Container Components，

containers从项目架构设计上来说并不是纯粹的components，当然它确实同时也具备components的特征，不过它扮演的角色是关联数据的容器，并且提供处理数据的功能，在dva中数据模型就是model，而components是不需要关心model的，里面的实现也不会跟model挂钩，也不会dispatch，简单的说我认为components的实现就跟antd的组件是一样的，职责单一而聚焦，跟框架无关。

所以区分出containers和components最明显的作用是让项目开发者在思维上对应用的组件进行划分，如果只提供components，那么Presentational and Container Components这两种类型的组件会混在一起，从而达到的效果是两者区分效果不明显，很容易混用。

@sorrycc 说的这种情况：

发现为了 connect 提取一个和 components 下的同名文件出来很蛋疼，尤其是 containers 下的文件多了之后

这种情况是可以避免的，比如我之前写的一个项目是这样划分的：

其中 container 扮演的角色就是一切跟model相互关联的操作，而 components 里面都是纯粹的 presentational components，如果在其中的 presentational components 的子组件还会跟 model 有关系，那么这个子组件又会是一个 container。

综上所属，containers 和 components 的区分更多是为了清晰开发者的思路，这样会让数据链路更加清晰。

[codering]

“ In an earlier version of this article I claimed that presentational components should only contain other presentational components. I no longer think this is the case. Whether a component is a presentational component or a container is its implementation detail. You should be able to replace a presentational component with a container without modifying any of the call sites. Therefore, both presentational and container components can contain other presentational or container components just fine ”

看到最后，我感觉作者好像在说“ It's up to you . ” 😏 。。。。然后我就更懵了

[sorrycc]

这篇文章出来好久了，感觉作者观点已变，包括他们的 f8app 都已经是 containers 和 components 混用了。

[nikogu]

这个问题， @sorrycc 要不就按照你的这个来了，也没什么大问题，确定一下：

.
├── /mock/
├── /src/
│ ├── /components/       # React components
│ ├── /models/           # model 信息
│ ├── /routes/           # 路由 Component
│ ├── /services/         # 处理和服务器的交互
│ ├── index.html
│ ├── index.js           # 应用入口
│ ├── index.less
│ └── router.js          # 路由配置
├── package.json
├── proxy.config.js
└── webpack.config.js

[sorrycc]

@nikogu 好的，先用这个吧。用 dva-cli@0.2.0 初始化出来就是这个目录结构。