fe-pagination
v1.0.1
Published
### 组件 `build` 为什么形态
Downloads
5
Readme
Thinking
组件 build
为什么形态
all in one?
在业务中无法分拆资源, 丧失资源依赖的可控性, 后期没法做优化
es5 -> es6?
单一转化 es6 文件意义不大, 如果在业务
loader
中排除node_modules
导致依赖分析时丢失其他资源文件, 其产出目录下还需完成对其他资源的处理styl -> css?
在代码中
import 'index.styl'
需要引入loader
才能转化为import 'index.css'
综上, 考虑到组件体系可以规范前缀 fe-
规则且与业务环境的基础 build
环境可以保持一致, 除了不考虑资源依赖的 fe-reset
等模块外, 组件产出并不进行任何 build
, 在业务中的追加 include
规则, 统一在业务中处理 build
theme
权衡重复开发成本与 UI 灵活性, 将 theme
抽象为 3 个颜色:
highlightColor
有意义的突出可读性的颜色(如文字颜色, 表单中的 "✔", 表意 icon 等)
primaryColor
主调背景颜色(如黑色风格设计中的黑色)
secondaryColor
辅助背景颜色, 常于主调颜色搭配避免色彩单调(如 Airbnb 设计中的砖红色)
组件内部对注入颜色进行合理分配, 其他的轻量颜色变化基于 HSL
酌情按简单规则处理, 如:
醒目: Lightness +20%
弱化: Lightness -20%
业务场景:
state: {
theme: {
highlightColor: '#fff',
primaryColor: '#2b2d2e',
secondaryColor: '#e00007'
}
}
<Button theme={this.state.theme} />
数据接口
强调 propsType
声明, 用于生成文档及单元测试尤其是表单组件自动生成后端接口
表单数据接口规范示例:
对于表单元素, 我们用基本的 key-value
格式描述
{
"taskName": {
"value": "默认值",
"type": "text",
"label": "任务名称"
}
}
意为一个 key
为 taskName
的文本型输入框, 默认值为 "默认值", 标签文本为 "任务名称", 在 submit
后我们会提交:
{
"taskName": {
"value": "用户输入值"
}
}
注意:
value
字段永远为字符串, 特别地, 在type
为bool
时 "0" ->false
"1" ->true
, 在type
为number
时, "0" -> 0
装饰属性:
用于修饰性的非关键信息, 根据产品需求选填
placeholder [
String
] 空值时的占位字符(一般灰色显示), 如: "请输入用户名"disabled [
Bool
] 控制元素默认是否禁用labelWidth [
Number
|String
] 控制标签宽度width [
Number
|String
] 控制整体宽度verify [
String
] 校验规则description [
String
] 额外的描述信息formater [
String
] 额外的格式化信息, 例如 type 为date
时:yyyy-MM-dd HH:mm:ss
@TODO
- [ ] babel-preset
- [ ] fe-button
- [ ] fe-dialog
- [ ] fe-icon
- [ ] fe-input
- [ ] fe-table