做网站时点击显示,长春建设股份有限公司,中企动力销售陪酒多吗,基于php的网站设计与实现本文首发于欧雷流。由于我会时不时对文章进行补充、修正和润色#xff0c;为了保证所看到的是最新版本#xff0c;请阅读原文。在本系列文章《聊聊前端 UI 组件#xff1a;组件体系》中初步说明了 UI 组件的架构设计#xff0c;本文将在此基础上进一步展开说说那篇文章中一…本文首发于欧雷流。由于我会时不时对文章进行补充、修正和润色为了保证所看到的是最新版本请阅读原文。在本系列文章《聊聊前端 UI 组件组件体系》中初步说明了 UI 组件的架构设计本文将在此基础上进一步展开说说那篇文章中一笔带过的部分并阐述在设计一个 UI 组件时应该注意的点有哪些。目录结构在《聊聊前端 UI 组件组件体系》中列出的目录结构的基础上做了些许调整——component├── demo # 示例相关文件│ └── ...├── test # 测试相关文件│ └── ...├── style # 样式相关文件│ ├── _functions.scss # Sass 函数(可选)│ ├── _properties.scss # CSS 自定义属性(必需)风格组件的一部分供外部运行时自定义主题风格│ ├── _variables.scss # Sass 变量(必需)风格组件的一部分供外部编辑时/编译时自定义主题风格│ ├── _mixins.scss # Sass 混入(可选)│ └── _rules.scss # CSS 规则(必需)视觉组件具有约束结构的作用├── typing # 类型相关文件│ ├── custom-properties.ts # CSS 自定义属性配置项(必需)用于运行时生成 CSS 自定义属性│ ├── aliases.ts # 类型别名(可选)│ ├── interfaces.ts # 结构组件接口(必需)│ └── index.ts # 类型统一导出├── HeadlessComponent.ts # 无头组件UI 组件与结构无关的逻辑├── Component.vue # 结构组件受生成 HTML 的 JS 库/框架的源码、平台限定的视图结构描述语言影响├── index.ts # 模块统一导出├── changelog.md # 组件变更记录├── readme.md # 组件说明文档├── metadata.yml└── package.json命名约定HTML CSS class在基于组件开发(Component-based Development)即大家所说的「组件化」在 web 前端领域普及之前流行过一种神奇的 class 命名方式可以说是一种方法论了——原子类(atomic classes)。估计一入行就是 React、Vue 横行的前端压根儿就没听过更没见过「原子类」是个什么东西——.w-100 { width: 100px; }.w-150 { width: 150px; }.h-100 { height: 100px; }.h-150 { height: 150px; }.m-10 { margin: 10px; }.m-20 { margin: 20px; }.mt-10 { margin-top: 10px; }.ml-15 { margin-left: 15px; }.bgc-red { background-color: red; }.bgc-greed { background-color: green; }.c-fff { color: #fff; }.c-000 { color: #000; }.f-l { float: left; }.f-r { float: right; }Atomic classes看到了吧这种方法论强调的就是尽可能将 CSS 的每个属性和值的组合拆成 class命名方式也基本是「属性名 属性值」的形式并且属性名和属性值是否进行「简写」以及中间有没有 -、_ 等分隔符就看编写的人的素养和心情了。原子类的「优点」是它把 class 拆分到足够细很好很「原子」原子化带来的特点就是可组合性很强这样任何页面都可以通过原子类的有机组合去实现只有想不到没有做不到哪天设计师说要把按钮距离左边的 15 像素改为 10 像素——没问题把 的 .ml-15 换成 .ml-10 就好小菜一碟为什么上面说的「优点」是加了引号的我就想知道原子类除了写的时候字符数可能会稍微少些跟写内联样式(inline style)有什么区别有更语义化吗可读性有变更好吗人脑负担有降低吗中、大型项目维护起来更方便吗随着基于组件开发在 web 前端领域的普及原子类的身影逐渐消失但最近因为某个 CSS 框架人气走高的原因原子类再度死灰复燃……那么原子类或者说样式原子化是错的吗不是都是时臣的错啊不都是 utility-first 思想的错class 应该是语义化的尤其是在基于组件开发时让在视图结构中一眼看到 class 后就知道它是个什么东西而不是它长什么样。另外基于组件开发的特点之一就是封装对外屏蔽内部细节而 utility-first 思想恰恰是暴露细节这与基于组件开发的理念「三观不合」。在基于组件开发的体系下class 理应是 component-first即应用 CSS 组件(CSS component)那些 utility class 作为辅助存在。也就是说当 CSS 组件自带样式与实际需求有些许不符时利用 utility class 进行「微调」而不是在外部重写 CSS 组件的样式——这也是一种组合方式。比如按钮 CSS 组件本身是不会在水平方向撑满容器的但设计师想让它占满一行——.Button {display: inline-block;text-align: center;}.u-block {display: block !important;}CSS componentCSS 组件在本系列文章所阐述的 UI 组件体系中叫做「视觉组件」class 的命名遵循 BEM 的变体——SUIT CSS 命名约定。SUIT CSS 是 Normalize.css 的作者 Nicolas Gallagher 于 2013 年左右时创立虽然现在已经处于基本不维护的状态了但它基于组件开发的思想仍发挥着余热。SUIT CSS 命名约定我从 2014 年用到现在并且会继续用下去。本系列文章 CSS 相关的示例代码中 class 的命名皆遵循此命名约定。在基于组件开发的体系下强烈建议 class 命名遵循 SUIT CSS 命名约定——/* 组件 */.ComponentName {}/* 组件修饰符 */.ComponentName--modifierName {}/* 组件后代 */.ComponentName-descendentName {}/* 组件状态 */.ComponentName.is-stateOfComponent {}/* 辅助工具 */.u-utilityName {}组件基类 .ComponentName 及其后代 .ComponentName-descendentName 很好理解它们天然具有层级关系共同描述了一个 UI 组件的结构——文章标题章节标题章节段落一些其他信息文章标题章节标题章节段落一些其他信息而组件修饰符 .ComponentName--modifierName 和组件状态 .ComponentName.is-stateOfComponent 有时就不能很好地区分何时该用哪个了。就拿按钮 CSS 组件来说它的颜色、是否可用与尺寸哪个该用修饰符哪个算是状态我给出一个比较简单的判断标准如果是 UI 组件的特性即不会因为什么条件而改变的用修饰符倘若会因某个条件满足与否而变化那就是状态——新增批量删除应该注意的是组件修饰符和组件状态都是直接加在 UI 组件的根节点上的也就是要跟在组件基类的后面不能用于组件后代上。假如一个组件后代需要程序化地改变它本身的样式要用辅助工具类而不是状态类。当一个组件后代的结构、功能等变得复杂时要将其封装成一个新的组件。Sass 变量与 CSS 自定义属性在本系列文章所阐述的 UI 组件体系中Sass 变量和 CSS 自定义属性合称为「风格组件」它们负责主题风格的定制是与设计体系(Design System)的结合点。其中Sass 变量是在编辑时/编译时CSS 自定义属性则是在运行时。在这里Sass 变量与 CSS 自定义属性的命名方式比较类似它们大概都是 -[-descendent-name|-modifier-name][-state]-(variable-name|property-name) 的形式。由于我在基于本系列文章所阐述的思想做一套叫做「Petals」的半成品 UI 组件因此之后的示例代码中涉及到的 部分基本都会用 petals。Sass 变量是以 $__petals 或 $petals 开头与组件名之间用 -- 连接前者是内部使用(私有)的上层开发者无需关心后者是供外部在编辑时/编译时定制用CSS 自定义属性则用 --petals 开头以 - 与组件名相连——/* 实际形式--(variable-name|property-name) */$__petals--button-font-size: --petals-button-font-size;$__petals--button-line-height: --petals-button-line-height;/* 实际形式----(variable-name|property-name) */$petals--button-primary-focus-color: var($__petals--primary-active-color, $petals--primary-active-color) !default;$petals--button-primary-focus-bg: var($__petals--primary-active-bg, $petals--primary-active-bg) !default;上文所说的 CSS 组件即视觉组件它是将样式进行封装对外屏蔽细节而风格组件相反通过将视觉组件所用到的 CSS 属性值动态化的方式达到样式可定制化的目的这就变得像 utility-first 的原子类一样暴露了样式细节。但与 utility-first 的 CSS 框架不同的是风格组件只给进行主题风格定制的人带来了心智负担对其他的上层开发者并无影响。业务无关本系列文章主要讨论的对象是业务无关的 UI 组件在单说「UI 组件」或「组件」时也是指这个而业务相关的 UI 组件在本系列文章所阐述的 UI 组件体系中叫做「部件」。根据 UI 组件的通用性可分为「通用组件」和「专用组件」。「通用组件」是能够满足大部分常规场景的 UI 组件它们的集合通常会作为「组件库」整体打包发布为一个软件包「专用组件」是为了解决某些特殊场景需求而存在的像数据网格、各种编辑器等这类一般都是单独发包。上面提到的「通用组件」和「专用组件」都是业务无关的 UI 组件。UI 组件是什么可以认为它是一个返回视图结构的函数而 UI 组件的属性(prop)和事件(event)就是这个「函数」的参数。属性是 UI 组件的外部与其内部进行主动通信的数据事件则是进行被动通信的回调函数。一个封装得好的函数它的参数应尽可能少要想明白每个参数的语义且必须确实有其存在的意义——UI 组件的属性和事件的设计也该如此。在设计 UI 组件的属性时先思考下要加的这个属性是不是属于这个 UI 组件本身的特性若不是那要加的属性的值所对应的 UI 组件的特性是什么如果这两个问题都没有得到答案那么这个属性可以不用加了。UI 组件的属性只应与其本身的特性有关与业务意义无关——自身特性是自然特性业务意义是附加特性。比如一个按钮组件通常会有「主要」、「次要」和「危险」这几种多少与业务沾边的语义那么组件的属性该如何设计来满足这种需求呢Ant Design 和 Element 的做法是将其作为 type 属性的值或独立成一个属性——Ant Design 中的主要按钮Ant Design 中的次要(默认)按钮Ant Design 中的危险按钮Element 中的主要按钮Element 中的次要(默认)按钮Element 中的危险按钮按照上面说的 UI 组件属性设计原则来看「主要」、「次要」和「危险」作用到按钮组件上的表现主要是颜色发生了变化所以应该去用表示按钮的自然特性「颜色」的 color 属性来满足同样的需求——主要按钮次要(默认)按钮危险按钮红色按钮黄色按钮蓝色按钮若 UI 组件的某组特性是二元对立的如「禁用」与「启用」则选择默认不生效的那个作为属性且属性值是布尔型默认值为 false。还是拿按钮组件来举例如果默认是「禁用」那就设计一个代表「启用」的 enabled 属性其默认值是 false只要组件在被使用时传入了 enabled就变成了「启用」状态反之亦然。另外UI 组件的属性值尽可能是简单数据类型也就是数字、字符串等。业务相关业务相关的 UI 组件即上文所说的「部件」因其关注点与业务无关的 UI 组件不同所以在设计时所遵守的原则和考虑的事情也不尽相同甚至会大相径庭。一般来说会用到上下文与依赖注入等技术。由于业务相关的 UI 组件不是本系列文章主要讨论的对象在此就不展开说了。总结前几天在朋友圈立了个 flag——本文就是该 flag 的「引子」。欢迎关注微信公众号【Coding as Hobby】(微信中搜「coding-as-hobby」)以及时阅读最新的技术文章 ;-)