You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
import MediaPlanViewChannel from '/MediaPlan/MediaPlanView/MediaPlanViewChannel.jsx';
// vs
import MediaPlanViewChannel from './MediaPlan/View/Channel';
React 作为一个库,它没有规定项目的整体结构。这很好,因为它给了我们自由去尝试不同的方法,并适应更适合我们的方式。另一方面,这可能会给React领域的开发人员带来一些困惑。
我将会在本文为大家展示我已经使用过一段时间并且效果不错的方式,这些方式没有通过重新造轮子来实现,而是通过将社区中的方案组合和提炼得到。
目录结构
我经常遇到的一个问题是如何组织文件和目录结构。在这篇文章中,我们认为你已有一个最小的结构,就像用
create-react-app
创建的结构一样。create-react-app
为我们生成了一个基础的项目,包含根目录还有诸如.gitignore
,package.json
,README.md
,yarn.lock
的文件。它还生成
public
和src
目录,src
目录是我们保存源代码的地方。请看下面的图片,以及描述的结构:
在这篇文章中,我们只关注
src
目录,src 之外保持不变。容器和组件 (Containers and Components)
你可能已经在某些项目的根目录下看到了容器和展示组件之间的分离。我的意思是,在
src
中,在 src 目录下有containers
目录和components
目录:但是,这种方法有一些问题,如下所示:
主观的规则:对于容器和展示组件,没有明确的规则。彼此之间的差异可能是主观的,当你在一个团队中时,很难让所有开发人员赞成并评判这个问题。
它没有考虑组件的动态性:即使当你决定某个组件适合于某个特定类型时,也很容易在项目生命周期中对其进行更改,使其从另一种类型变为另一种类型,最终迫使你把它从
components
挪到containers
目录下,反之亦然。允许两个具有相同名称的组件:组件的命名在应用程序中具有声明性和惟一性,以避免混淆每个组件的职责。但是,上面的方式破坏了具有相同名称的两个组件,一个是容器,另一个是展示示组件。
效率低下: 即使你在实现一个独立特性时,也不得不经常在
containers
和components
目录下来回切换,因为一个独立特性有两种不同类型的组件是再正常不过的事情了。还有一种方法,在模块内部保存
containers
和components
分离:上述方法最大限度地减少了在项目树中不同层级目录切换的问题。然而,它会增加很多噪音。根据你的应用程序有多少模块,你最终会创建几十个
containers
和components
目录。出于这些原因,当我们谈论组织目录和文件时,通过展示与容器的概念来拆分组件是无关紧要的。 也就是说,除页面外,我们将把所有组件放在
components
目录下。拆分和组合代码
在
components
目录中,我们按模块/功能对文件进行分组。在用户的增删改查中,我们只有
User
模块,结构是这样的当组件由多个文件组成时,我们将此组件及其文件放在具有相同名称的目录下。 例如:假设有一个包含
Form.jsx
样式的Form.css
。 在这种情况下,你的结构如下:UI 组件
除了通过模块拆分组件之外,我们还在
src/components
中包含一个UI
目录,以保留其中的所有通用组件。UI 组件是通用的组件,不属于模块。 它们是可以保留在开源库中的组件,因为它们没有来自特定应用程序的任何业务逻辑。 这些组件的示例包括:按钮,输入,复选框,选择,模态框,数据可视化组件等等。
命名组件中的类
上面我们看到了如何构建目录并按模块分离我们的组件。 但是,还有一个问题:如何命名它们?
当我们谈论命名组件时,它涉及我们给类或定义组件的常量名称:
如上所述,我们为组件提供的名称应该在应用程序中清晰且独特,以便更容易找到并避免可能的混淆。
当我们需要使用工具作为React Dev工具进行调试时,以及当应用程序中发生运行时错误时,组件的名称非常方便,错误总是与发生错误的组件名一起出现。
我们采用基于路径的组件命名方式,即根据相对于
components
文件目录的相对路径来命名,如果在此文件夹以外,则使用相对于src
目录的路径。举个例子,组件的路径如果是components/User/List.jsx
,那么它就被命名为UserList
。当文件位于具有相同名称的组件中时,我们不需要重复该名称。 也就是说,
components/User/Form/Form.jsx
将被命名为UserForm
而不是UserFormForm
。上面的模式有一些好处,我们可以在下面看到:
便于在项目中搜索文件
如果编辑器支持模糊搜索,只需搜索名称
UserForm
就可以找到正确的文件如果你想要在目录中搜索文件,可以很容易地通过组件的名字定位到它:
避免在导入重复名称
按照该模式,可以始终根据文件的上下文为组件命名。考虑到上面的表单,我们知道它是一个用户表单,但是由于我们已经在
User
目录中 ,所以不需要在组件文件名中重复这个单词。因此,我们只将它命名为Form.jsx
。我最初使用 React 的时候喜欢用完整的名字来命名文件,但是这样会导致相同的部分重复太多次,同时引入时的路径太长。来看看这两种方式的区别:
在上面的示例中,可能无法看到从一种方法到另一种方法的优势。 但是应用程序名称多了话,就可以看到差异, 如下:
想象一下名称重复十几二十次的样子。
因此,我们根据文件 的上下文来命名文件,根据组件的相对位置来命名组件是一种更好的方式。
页面(Screen)
屏幕,顾名思义,就是我们在应用程序中展示出来的样子。
如果要对一个用户做增删改查的操作,我们需要有用户列表页面,创建新用户的页面以及编辑已有用户的页面。
我们将
screens
保存在src
根目录中的单独文件夹中,因为它们将根据路由定义而不是模块进行分组:考虑到项目使用
react-router
,我们将文件Root.jsx
放在在screens
目录下,并在其中定义所有应用程序路由。Root.jsx 的代码可能像下面这样:
请注意,我们将所有页面放在一个目录中,这个目录以路由名称命名,
user/ -> User/
。尝试为每个父级路由建立一个目录,在这个目录中组织子路由。 在这种情况下,我们创建了User
目录,并将List
页面和Form
页面放入其中。这种方式使你看一眼 url 就能够轻松定位当前路由渲染的页面。单个页面可用于渲染两条不同的路线,如上所述,其中包含用于创建和编辑用户的路线。
你可能会注意到所有组件都将
Screen
作为其名称的前缀。 当组件位于components
目录之外时,我们应该根据它到src
文件夹的相对路径来命名。 位于src/screens/User/List.jsx
的组件应命名为ScreensUserList
。创建 Root.jsx 后,目录的结构如下:
如果你对一个页面长什么样子还有疑问,看看下面的示例,它就是用户表单的页面。
最后,我们的应用程序结构如下:
简要回顾
展示组件和容器组件保存在
src/components
按模块/功能对组件进行划分
UI组件放大
src/components/UI
保持页面简单,结构和代码最少
通过路由定义组织页面。对于
/user/list
路由地址来说,我们会有一个页面在/src/screens/User/List.jsx
。组件根据其与组件或src的相对路径进行相应命名。 鉴于此,位于
src/components/User/List.jsx
的组件将被命名为UserList
。 位于src/screens/User/List
的组件将命名为ScreensUserList
组件和目录同名时,不要在使用组件的时候重复这个名字。考虑这样一个场景,处于
src/components/User/List/List.jsx
位置的组件会被命名为UserList
而不是UserListList
。** 原文:https://hackernoon.com/structuring-projects-and-naming-components-in-react-1261b6e18d76 **
你的点赞是我持续分享好东西的动力,欢迎点赞!
欢迎加入前端大家庭,里面会经常分享一些技术资源。
The text was updated successfully, but these errors were encountered: