首页 > 财经 >

React 项目结构和组件命名之道

2018-11-15 01:33:02 网络整理 阅读:103 评论:0

React 作为一个库,不会决定你如何组织项目结构。这是件好事,因为这样我们有了充分的自由去尝试不同的组织方式并且选取最适合我们的方式。但是从另一个角度讲,这可能会让刚刚上手 React 的开发者产生些许困惑。

我将会在本文为大家展示我已经使用过一段时间并且效果不错的方式,这些方式没有通过重新造轮子来实现,而是通过将社区中的方案组合和提炼得到。 注意:这里没有什么是绝对正确的!你可以选择你认为容易理解,并且可以适应或可以改造成适应你的情景的方式。 目录结构

我最常见到的一个问题就是如何组织文件和目录结构。在本文中,我们假设你有一个 create-react-app 生成的最简单的目录结构。

create-react-app 为我们生成了一个基础的项目,包含根目录还有诸如.gitignore, package.json, README.md, yarn.lock 的文件。

它还生成了 public 和 src 目录,src 目录就是我们存放源代码的目录。

看一下下面图片所描述的结构:

React 项目结构和组件命名之道

本文我们只会关注 src 目录,所有在它之外的都会保持不变。 容器和组件

我们可以看到在 src 目录下有 containers 目录和 components 目录:src├─ components └─ containers

但是这个方式会导致下面这些问题:主观的规则 你不清楚什么是容器而什么是组件,这两者的差异是主观定义的。如果在你的团队里去推行,让所有的开发者能够相同地赞成和评判这两者是非常困难的。没有考虑组件的变化 即使你决定了一个组件适用于某种特定的种类,在项目的周期内很容易发生变化,最终迫使你把它从 components 挪到 containers 目录下,反之亦然。允许两个组件使用同一个名字 组件在应用中的命名应该是声明式且唯一的,从而避免对相同命名组件的职责产生困惑。但上面的方式为两个组件可以拥有相同命名打开了一个缺口,一个可以是容器,另一个可以是展示型组件。效率低下 即使你在实现一个独立特性时,也不得不经常在 containers 和 components 目录下来回切换,因为一个独立特性有两种不同类型的组件是再正常不过的事情了。

相关文章