构造无礼:告别原子设计的歧义

原子设计是一种概述样式表合理代码结构的方法。 它拥有大量的追随者,但我发现其命名约定有时可能是模棱两可的。 什么是分子? 什么是生物体? 我们如何知道两者之间的界限? 这些特定问题似乎是解释原子体系结构的最大绊脚石。

今天,我们将讨论我使用的东西,我在努力使用的原子设计约定的特定方面,为解决问题而做的工作以及当前如何使用7-1模式组织Sass。

编者注

此后 ,《原子设计》的作者布拉德·弗罗斯特(Brad Frost) 澄清了一个事实,即其方法论实际上并不决定任何CSS结构。 相反,它提供了一种思维模型来考虑构建用户界面。 抱歉,布拉德!

原子结构

“我们不是在设计页面,而是在设计组件系统。”- Stephen Hay

我喜欢原子设计及其意识形态,但是我发现当与不十分熟悉其全部工作原理的团队成员一起工作时,它们可能会崩溃。 过去,我使用以下文件夹结构:

文件夹组织: root/css/src/

- vars
 - functions
 - mixins
 - base
 - plugins
 - typography
 - atoms
 - molecules
 - organisms
 - templates
 - pages
 - states
 - utility
 style.scss

style.scss中,使用style.scss -sass-glob-import导入 Sass部分:

Sass导入索引文件: root/css/src/style.scss

// Config
@import "vars/*";
@import "functions/*";
@import "mixins/*";

// Bower Components
@import "../bower_components/normalize-scss/_normalize";

// General DOM selector styles
@import "base/*";

// Fonts & General Type Styling
@import "typography/*";

// 3rd Party Addons
@import "plugins/*";

// Atomic Design
@import "atoms/**/*";
@import "molecules/**/*";
@import "organisms/**/*";
@import "templates/**/*";
@import "pages/**/*";

// Variations thru Events
@import "states/*";

// General UI Helpers
@import "utility/*";

此设置的顺序很重要。 如果需要调整“原子”,“分子”或“有机体”,则在模板或页面中进行的声明将覆盖上述部分以及所有其他部分前面的内容。

该命令还可以在需要时(通常以我的经验)启用对插件样式的覆盖。

目录内容

每个原子目录的大部分内容(原子,分子,生物,模板,页面)将包含部分内容,这些部分在理论上很容易找到,并在需要时易于管理。

- atoms
   - _buttons.scss
   - _links.scss
   - _inputs.scss
 - molecules
   - _navigation.scss
   - _search-form.scss
   - _contact-form.scss
 - organisms
   - _header.scss
   - _footer.scss
   - _content.scss
 - templates
   - _sticky-footer.scss
   - _grid-2column.scss
   - _grid-3column.scss
 - pages
   - _home.scss
   - _about.scss
   - _contact.scss

如果您明智地使用Atomic Design,则该组织似乎很明智,但对于不熟悉这种方法和术语的人来说,这是不够的。 不了解Atomic Design的开发人员不会理解搜索表单位于molecules目录内的事实,可能会开始在其他区域进行搜索以进行编辑,或者只是感到沮丧而制作新文件。 我已经看到了它的发生。

组件结构

在撰写本文时,我采用了一种方法,将元素完全设想为组件,例如lego块,从而为与代码库有关的所有对象提供了易用性。 看一下以下目录结构:

- vars
 - functions
 - mixins
 - base
 - typography
 - plugins
 - toolbox
 - components
 - layout
 - pages
 - states
 - utility
 style.scss

希望您可以通过此示例看到,收集每个文件夹的用途非常直观(工具箱除外)。 “工具箱”是一个用于存储与实用程序无关的帮助程序的地方,例如布局和对象模式的自定义类,自定义关键帧动画等。 对我来说,这些工具箱项通常最终会成为我可能会覆盖或将来要替换的部分,以及为什么将它们导入到components目录之前。

在此阶段,将部分文件加载到样式索引中,如下所示:

// Config
@import "vars/**/**";
@import "functions/*";
@import "mixins/*";

// UI
@import "../bower_components/normalize-scss/_normalize";
@import "base/*"; // general styling using DOM element selectors
@import "typography/*";
@import "plugins/**/*"; // 3rd party add-ons
@import "toolbox/**/*"; // Non-Utility Helpers
@import "components/**/*"; // lego blocks
@import "layout/**/*";
@import "pages/**/*";
@import "states/**/*";
@import "utility/**/*";

“组件”将包含UI的各个部分,例如按钮,输入,徽标,化身,页眉,页脚,表单,甚至模块,例如导航。 组件可以是任何东西,只要它们只做一件事情和一件事情,就可以重复使用,可以在整个项目中重复使用,而且最重要的是独立。 如果您问我,这是一个不容易被普遍理解的定义。 这种特殊的方法还实现了SMACSS状态 )和Atomic Design( 模板在此示例中称为布局和页面 )的各种思想。

在查找方式方面,找到组件目录和查找开发人员可能正在跟踪的相关接口部分要容易得多; 例如:

- components
   - _buttons.scss
   - _navigation.scss
   - _masthead.scss
   - _footer.scss
   - _logo.scss
   - _avatar.scss
   - _contact-form.scss
   - _sales-calculator.scss

本质上,组件是一站式服务。 原子设计可能适合一个团队甚至一个非常熟悉的团队使用,但是在较大的团队中可以感觉到沮丧。

结论

原子设计绝对可以用来使元素的样式保持最少,以便创建有意义且可重用的界面组件。 但是您可能会发现某些方面令人困惑。 自己决定什么最适合您,然后得出结论。 对于所有内容,这只是我的经验,其他人可能有不同的立场。

我很想听听您如何处理这种情况,因此请在评论中告诉我。 祝大家编码愉快!

翻译自: https://webdesign.tutsplus.com/articles/structuring-sass-saying-goodbye-to-atomic-design-ambiguity--cms-26679

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值