关于react.js:数栈技术分享利用-Atomic-构建-React-项目工作流so-easy

45次阅读

共计 2099 个字符,预计需要花费 6 分钟才能阅读完成。

​数栈是云原生—站式数据中台 PaaS,咱们在 github 和 gitee 上有一个乏味的开源我的项目:FlinkX,FlinkX 是一个基于 Flink 的批流对立的数据同步工具,既能够采集动态的数据,也能够采集实时变动的数据,是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个 star!star!star!

github 开源我的项目:https://github.com/DTStack/fl…

gitee 开源我的项目:https://gitee.com/dtstack_dev…

用过 React 的敌人都晓得,React 我的项目文件夹的划分是有很多种的,在 React 官网对于文件构造这个局部给出了一些社区比拟常见的构建形式的示例。例如有通过 features 或者 routes 进行分组的,也有通过模块类型(type) 划分的。在文档提到了一种针对 components 进行细化组织的办法 —— Atomic Design。如果还没理解过这个设计办法的敌人,无妨来看一看。
一、什么是 Atomic

Atomic 是一套领导设计前端组件(Components)架构的办法。在咱们的日常工作中,如何更好的划分和治理前端组件经常会是咱们碰到的问题。Atomic 通过一系列设计思维和准则,能够很好领导咱们的我的项目架构。用 Atomic 作者本人的话说,这套设计办法的灵感是来自于本人已经学习过的化学课,以及对天然常识自身的思考。作者通过原子(Atoms)、分子(Molecules)、有机体(Organisms)、模板(Templates), 页面(Pages) 这 5 种根本类型组件,通过灵便的组合,从而来满足咱们日常的页面开发需要。

1、原子(Atoms)

正如化学常识中所表述的,原子(Atoms)是元素能放弃其化学性质的最小单位,所以正好利用原子的概念,能够用来组件零碎中的最小单位的组件,或者说形象到最小粒度的组件,即咱们在 HTML 中常见的一些根本元素,例如:按钮(buttons),表单标签 (labels),输出控件(input) 等等。既然是最小单位,Atom 类型的组件显然是无奈再进行任何拆分了,如果能持续拆分,那么该组件应该被划分为分子组件(Molecules)。

2、分子(Molecules)

咱们都晓得,在化学概念中,分子是有若干原子组成。通过组合各种原子组件,咱们能够轻易的能够组合出某种性能的分子组件。例如通过组合 input 控件和 button 组件,咱们能够失去一个搜寻(Search)分子组件,通过组合 button 和 a 标签,能够能够组合分页(Pagination)组件。

3、有机体(Organisms)

仅靠分子组件和分子组件的形象,依然是不能满足咱们理论工作中对组件复用的需要,例如咱们咱们大部分我的项目中都有导航栏(Navigation Bar)、页头(Header)、页脚(Footer)、边栏(Sidebar)、列表(List) 等等组件,显然能够依据须要能够形象成独立组件,以便起初的我的项目能够间接应用。能够看到的是,在有原子和分子组件的状况下,咱们通过灵便组合这些原子、分子组件的形式,便可轻易达到咱们的需要。而通过这类形式组合的组件类型咱们便称之为有机体组件(Organisms)。

4、模板(Templates)

到这里,模板层就很好了解了。很显然,模板层是原子、分子、有机组件的结合体。例如蕴含头部(Header、Content、Footer)常见局部的首页模板、又或者各种左右高低布局模板组件等等。

5、页面(Pages)

页面这一层可能是复用率最低的一层了,因为业务需要大部分时候各不相同的,当然也不排除有复用页面的状况。页面组件天然就是个蕴含了其余四种组件类型的综合体了。有了前几层组件的形象,能够轻松的应答各种业务页面,并且一直地能够丰盛新组件到各类型本人中去,以便前面的我的项目中继续应用。

综合看下来,通过这 5 种组件的划分,就能够很好的满足咱们理论我的项目中对页面组件进行划分和治理了。


二、Atomic 实际

依据 Atomic 的思路, 以 src 目录为根底,在 React 我的项目中,我能够失去了相似如下的开发目录:

当然,像我通常喜爱把 pages 的层级进步,也就是把他与 components 同层,也就是:

这里有个仓库 Demo 能够参考:

https://github.com/wewoor/ato…
三、总结

在理论工作中,往往咱们会援用第三方的组件库,所以很多粒度组件都不须要咱们编写,或者说须要咱们独立编写的只有很少一部分,那么能够依据本人的理论情况来适当的缩减目录构造,包含目录名称,在跟我的项目成员沟通达成统一的状况下,也能够用其余的命名规定。如果你正在设计一个残缺的 UI 组件零碎的话,或者你在开发一个大型的 Web 零碎,那么更具体的划分规定可能会更有利于前期的保护和开发了。

Atomic 始终是一套设计思维,在实践中咱们能够更灵便的依据本人业务,团队的状况进行适合的调整,从而更好的满足咱们的开发需要。

更具体内请看 Atomic Design:

http://atomicdesign.bradfrost…

正文完
 0