From c77dec2bcc4f428bac9270012c665e63a8b3e201 Mon Sep 17 00:00:00 2001 From: liuhuan14 Date: Wed, 22 Jul 2020 11:10:10 +0800 Subject: [PATCH 1/6] =?UTF-8?q?fix=EF=BC=9A=E4=BF=AE=E6=94=B9md=E6=A0=BC?= =?UTF-8?q?=E5=BC=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../_posts/2020-07-21-618-what-taobao-do.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/source/_posts/2020-07-21-618-what-taobao-do.md b/source/_posts/2020-07-21-618-what-taobao-do.md index 4affb954ac..919fe65a5c 100644 --- a/source/_posts/2020-07-21-618-what-taobao-do.md +++ b/source/_posts/2020-07-21-618-what-taobao-do.md @@ -1,14 +1,15 @@ ---- title: 618前端竞品分析研究（互动篇） -author: 蔡洁莹 -date: 2020-07-14 18:00:00 -tags: [AI, 竞品分析] -category: 深入学习 -toc: true -comments: true -mathjax: true -description: 2020年的618大促活动中，友商在技术方案上做了较多的创新；从一个竞争者的角度来说，这一系列技术创新，有几个问题是值得我们去思考的：对于我们没有的，有哪些是可以学习效仿的？对于我们已有的，我们的差异化在哪里？哪些地方是我们做到了，而友商欠缺的呢？带着这几个问题，本系列主要从互动线、会场线、基础架构三个部分展开竞品研究，本文主要探讨友商在2020年618的列车互动中，是如何提升研发效率和产品稳定性的。 +subtitle: +cover: https://img11.360buyimg.com/imagetools/jfs/t1/143646/10/3554/261669/5f17ace1Eeb78f1bc/e5a72cd79d556c62.jpg +category: 经验分享 +tags: + - AI + - 竞品分析 +author: + nick: 蔡洁莹 +date: 2020-07-21 18:00:00 --- + ## 智能化测试 在互动中经常需要维护**大量的状态**，对这些状态进行**测试验证成本较高**，尤其是当有功能变动需要回归测试的时候。为了降低开发测试的成本，在这方面使用**强化学习模拟用户行为**，在两个方面提效： - **mock接口**：将学习过程中的状态作为服务接口的测试数据； From 66c30507e2451c644602aa7a77497cc8d6e2591c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=88=98=E6=AC=A2?= Date: Thu, 23 Jul 2020 15:56:57 +0800 Subject: [PATCH 2/6] =?UTF-8?q?fix:=20=E4=BF=AE=E6=94=B9=E6=96=87=E7=AB=A0?= =?UTF-8?q?=E6=A0=BC=E5=BC=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../2020-07-21-how-to-use-grid-layout.md | 26 +++++++++++-------- source/_posts/2020-07-21-mobile-top-nav.md | 18 +++++++------ 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/source/_posts/2020-07-21-how-to-use-grid-layout.md b/source/_posts/2020-07-21-how-to-use-grid-layout.md index ef8e9dd426..7419f4bc97 100644 --- a/source/_posts/2020-07-21-how-to-use-grid-layout.md +++ b/source/_posts/2020-07-21-how-to-use-grid-layout.md @@ -1,20 +1,24 @@ ---- title: 如何使用Grid Layout -date: 2020-07-14 10:24:35 -categories: CSS应用 -tags: [grid, layout] -author: 何思源 +subtitle: +cover: https://img12.360buyimg.com/imagetools/jfs/t1/137873/20/3653/119351/5f1940ecE455fd637/158c0c6eb2163b18.jpg +category: 经验分享 +tags: + - grid + - 布局 +author: + nick: 何思源 +date: 2020-07-23 18:00:00 --- -#如何使用Grid Layout -##前言 +# 如何使用Grid Layout +## 前言 CSS Grid Layout是一种栅格布局，随着各大浏览器的兼容，在可应用范围越来越广。很多人就会问能不能代替Flexbox弹性布局？虽然他们有点相似，但值得一提的是他并不能代替Flexbox弹性布局，它可以在复杂的应用场景下与Flexbox弹性布局相辅相成。该属性的理念有点类似以往在网页设计中的栅格布局，如果以前接触过网页的栅格系统会帮助理解CSS Grid Layout。 -##兼容性 +## 兼容性 截止到20年7月14日，caniuse的兼容图。如图所示： ![avatar](https://img11.360buyimg.com/ling/jfs/t1/123375/21/7070/220446/5f0d5b5aE710ed109/0004d4c17daeefa8.png) -##应用场景 +## 应用场景 先来看看应用场景，个人十分推荐它用于大型页面框架构建或者电商中的sku列表摆放。具体可以来看看这两个demo图都附录了源码地址。 @@ -26,7 +30,7 @@ CSS Grid Layout是一种栅格布局，随着各大浏览器的兼容，在可 ![avatar](https://img12.360buyimg.com/ling/jfs/t1/122159/9/7091/434368/5f0d611bE53cd131a/9bb67298fd5be8b1.png) -##重要属性介绍 +## 重要属性介绍 ①.display: grid/inline-grid; 需要在包裹子元素的父容器上做出声明，该属性声明为CSS Grid Layout有两种，一种是块状元素display: grid，一种是行内块状元素display: inline-grid。该属性声明后其他属性才会有效。如图所示： @@ -80,6 +84,6 @@ rows是代指行，columns是代指列，用来声明高或宽 -##扩展阅读 +## 扩展阅读 1. [CSS Grid Layout Module Level 1](https://www.w3.org/TR/css-grid-1/) 2. [CSS Grid Layout Module Level 2](https://www.w3.org/TR/css-grid-2/) \ No newline at end of file diff --git a/source/_posts/2020-07-21-mobile-top-nav.md b/source/_posts/2020-07-21-mobile-top-nav.md index 5da1a415c4..e7415a8dc7 100644 --- a/source/_posts/2020-07-21-mobile-top-nav.md +++ b/source/_posts/2020-07-21-mobile-top-nav.md @@ -1,12 +1,14 @@ ---- title: 移动端吸顶导航组件的实现 -author: 李杰 -date: 2020-07-16 18:00:00 -tags: [组件, vue] -category: 经验总结 -toc: true -comments: true -mathjax: true +subtitle: +cover: https://img11.360buyimg.com/imagetools/jfs/t1/116365/37/13099/111570/5f194260E4adb747f/4650859bee37a6ca.jpg +category: 经验分享 +tags: + - 组件 + - nav + - scroll +author: + nick: 李杰 +date: 2020-07-23 18:00:00 --- ## 前言 From 38848e437f662d3796ac016e4377ccfdf9cadd7c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=88=98=E6=AC=A2?= Date: Mon, 27 Jul 2020 10:00:07 +0800 Subject: [PATCH 3/6] =?UTF-8?q?=E6=8A=95=E7=A8=BF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../2020-07-24-line-height-in-all-hardware.md | 183 +++++++++ .../2020-07-27-how-to-use-react-docgen.md | 348 ++++++++++++++++++ 2 files changed, 531 insertions(+) create mode 100644 source/_posts/2020-07-24-line-height-in-all-hardware.md create mode 100644 source/_posts/2020-07-27-how-to-use-react-docgen.md diff --git a/source/_posts/2020-07-24-line-height-in-all-hardware.md b/source/_posts/2020-07-24-line-height-in-all-hardware.md new file mode 100644 index 0000000000..2528b691b7 --- /dev/null +++ b/source/_posts/2020-07-24-line-height-in-all-hardware.md @@ -0,0 +1,183 @@ +title: 几种移动端多平台元素垂直居中解决方案总结 +subtitle: +cover: https://img11.360buyimg.com/imagetools/jfs/t1/116365/37/13099/111570/5f194260E4adb747f/4650859bee37a6ca.jpg +category: 经验分享 +tags: + - CSS + - 兼容性 + - 移动端 + - line-height +author: + nick: 刘欢 +date: 2020-07-24 18:00:00 +--- +## 前言 + +在PC时代，垂直居中就是一个会引起很多讨论的问题，例如经典问题：如何在任何容器里，让任意行数的元素都能垂直居中，相信很多同学对于这个问题还记忆尤深。如今移动端已经成为了我们的主要平台，随之而来的问题也更加复杂。 + +而作为大促前端，我们的问题更加复杂，我们需要兼容大量不同平台的手机，例如：安卓4.4系统、IOS8、IOS9等等远古手机。可能有同学很好奇为何还需要花费时间去兼容这些手机，原因很简单：数据支撑，京东大促的用户量级非常巨大，虽然这些手机用户占比很少，但是当用户基数达到一定数量时，即使占比很小，数量也是很可观的，对应而来的就是各种客诉，所以我们必须兼容这些手机。 + +本文将从以下场景讨论问题的解决方案。 + +### 主要诉求： + +- 文字小于12px在安卓和ios表现不同； +- 文字在一定宽度下自适应，超过一定宽度需要截断； +- 文字配图标或者其他元素； +- 不使用JS，纯CSS； +- dom节点只有2层，比如 +``` +
任何元素内容
； +``` + +- 必须兼容IOS9及以下和安卓4.4.4，所以首先被排除的方法就是flex布局； +**PS. 本文不讨论PC下的展示效果** + +**主要问题：** + +假如设计稿高度为28px，我们如果把行高写成28px，那么在IOS和安卓下，必然是会出bug的，相信实践过的朋友都知道，同样的行高，IOS下没什么问题，但是在安卓下，文字是偏上的，如图所示： + + +![安卓下效果](https://img12.360buyimg.com/imagetools/jfs/t1/131832/30/5195/4631/5f1a929dE2bbe6b18/4becd8474555299c.jpg) + +经典问题了，怎么解决呢，根据网上的经验，都是建议使用flex布局的align-items来布局，但是这种布局不支持4.4.4的安卓手机，所以不行，同理grid也是不行。 + +#### 方法一：table布局 + +我尝试使用了table来进行布局，如果不考虑截断的问题，是可行的，缺点是必须2层结构，否则无法实现文字截断的效果，效果如下： +![table布局](https://img11.360buyimg.com/imagetools/jfs/t1/143483/16/3698/1989/5f1a965fE93925e30/69d9a9dd19898356.png) + +代码如下： +```html +
文字文字文字文字文字文字
+``` +```css +.word { + font-size: 10px; + background: red; + color: white; + display: inline-table; + padding: 0 10px; + table-layout: fixed; + width: 100px; +} +.word span { + display: table-cell; + height: 22px; + vertical-align: middle; + overflow: hidden; + text-overflow: ellipsis; + white-space: nowrap; +} +``` +**PS:table布局同样适用于2行纯文字，但是无法截断。** + +#### 方法二：line-height: normal + +我们还可以使用line-height: normal的方法来实现，效果如下： +![line-height:normal方法](https://img10.360buyimg.com/imagetools/jfs/t1/126259/29/7869/1939/5f1a9c91E40c83107/0ae8f8567dbe0a9b.png) +代码如下： +```css +.word { + font-size: 10px; + background: red; + color: white; + display: inline-block; + padding: 3px 10px; + width: 100px; + overflow: hidden; + text-overflow: ellipsis; + white-space: nowrap; +} +.word span { + line-height: normal; +} +``` +缺点：必须多套一层结构 +**PS:line-height: normal的元素不能设置高度，只能使用padding或者margin来模拟高度** + +#### 方法三：？？？ + +我们都知道，安卓下的文字是偏上的，所以我就把line-height**加高了几个像素**，奇迹发生了，安卓下居中了，IOS基本没变，绝了！ +经过试验，line-height值需要比height值大2px即可，IOS对这个值的敏感度非常小，只要不大于这个值，就几乎不变。 + +安卓： +![安卓](https://img14.360buyimg.com/imagetools/jfs/t1/146808/30/3723/1972/5f1a9f36E36f80854/d7b8bc8e9f9d613a.png) +IOS： +![IOS](https://img12.360buyimg.com/imagetools/s250x250_jfs/t1/115380/3/13060/4649/5f1aa64bE7cd0b4db/8eabb597357da84a.png) +``` +
文字文字文字文字文字文字
+.word { + font-size: 10px; + background: red; + color: white; + display: inline-block; + padding: 0 10px; + line-height: 24px; + height: 22px; + width: 100px; + overflow: hidden; + text-overflow: ellipsis; + white-space: nowrap; +} +``` +这个方法的应用场景在哪呢，**文字+icon+需要截断+自定义宽度**，经过研究，我发现，这种情况下，如果不使用js或者hack，是不可能使用纯CSS的办法完美解决的，所以使用该方法，可以保证在所有安卓和IOS的差距保持在一个设计师可以接受的范围内。 + +效果如下： +安卓： +![安卓](https://img10.360buyimg.com/imagetools/jfs/t1/123511/21/7979/4688/5f1aa254E3edfc64d/1a55b1d3a8c345a8.png) +IOS： +![ios](https://img13.360buyimg.com/imagetools/jfs/t1/113930/16/13208/7851/5f1aa254E46932fcc/7de86268cfd3b61c.png) +代码如下： +```scss +.word { + display: inline-block; + border-radius: 4px; + color: #fff; + background: #E8220E; + text-align: left; + overflow: hidden; + font-size: 20px; + max-width: 180px; + white-space: nowrap; + vertical-align: top; + padding: 0 6px 0 6px; + height: 28px; + line-height: 32px; + + &__pre { + display: inline-block; + vertical-align: top; + padding-right: 4px; + line-height: 30px; + } + &__text { + display: inline-block; + vertical-align: top; + width: calc(100% - 20px); + text-overflow: ellipsis; + white-space: nowrap; + overflow: hidden; + table-layout: fixed; + } +} +``` +该方法使用了calc来计算整体宽度，来实现文字截断。这种方法能够兼容一行下的大部分情况，支持**图标+文字**、**文字+文字**。 +缺点：IOS下可能还是会稍偏一点点，但是根据我们设计师的反馈，该误差可以接受，且该方法支持**一行多个同时出现**。 + +## 总结 + +- 根据实践，大部分情况下，方法3是覆盖面比较广的方法，line-height的值 > height的值即可； +- 如果只有一行文字，建议使用line-height: normal； +- 多行文字建议使用table布局，控制字数，因为无法截断； + + + + + + + + + + + diff --git a/source/_posts/2020-07-27-how-to-use-react-docgen.md b/source/_posts/2020-07-27-how-to-use-react-docgen.md new file mode 100644 index 0000000000..c812685e69 --- /dev/null +++ b/source/_posts/2020-07-27-how-to-use-react-docgen.md @@ -0,0 +1,348 @@ +title: 使用react-docgen自动生成组件文档 +subtitle: +cover: https://img11.360buyimg.com/imagetools/jfs/t1/130776/40/5374/245181/5f1e34d7Eaa6f1bf4/bbc19f2f98f318a0.jpg +category: 经验分享 +tags: + - react + - 组件 + - docgen + - 文档 +author: + nick: 朱鸣辉 +date: 2020-07-27 09:00:00 +--- +## 背景 + +最近在接到一个开发 React 组件库的需求，组件库在开发过程中，刚写完一个组件打算给同事用，同事立马来了个灵魂拷问“啊？这个组件怎么用”。emmm，我寻思直接告诉它下一次又忘了，还是老老实实写个文档吧。 + +文档写到一半，@#%#¥……#@麻烦死了。这么多组件，每个组件都需要有对应的文档，写起来太耗时了，手写文档比写个组件还麻烦。为了能快点完（xia）成（ban）任（hui）务（jia）。于是研究下那些**优秀的组件库**到底是怎么做的，看了下京东凹凸实验室的`Quark`夸克组件库的文档生成，大受启发，以下内容是讲讲关于如何优雅地偷懒并把组件文档都做好的。 + +## 为什么要自动生成文档 + +聊这个事情之前，我们先看看文档希望长什么样子 + +![组件文档](https://user-gold-cdn.xitu.io/2020/7/25/17386074a8124686?w=2580&h=1724&f=png&s=293455) + +组件文档需要什么内容 + +- 提供组件的介绍说明 +- 提供组件的属性列表 `propTypes` +- 提供组件调用的案例 `usage` +- 提供组件调用的演示案例/源码 + +如果要把这些内容都通过 `markdown` 去写，写完耗费的时间可能比做一个简单的组件还多，为了把更多的精力投入到开发更优质的组件当中，我们需要**文档生成自动化**。 + +文档自动化后能为我们带来什么？ + +- **统一**文档格式，抹平不同开发者写文档的格式差异 +- **节省**写文档的时间来做更多有意（tou）义（lan）的事情 + +我们拿一个小案例来尝试一下 + +## react-docgen + +开始进入正题，先简单介绍下文档自动生成的主角 `react-docgen` ，官方对于它的介绍是这样的： + +> react-docgen 是一个 CLI 和工具箱，可帮助从 React 组件中提取信息并从中生成文档。它使用 ast 类型和@ babel / parser 将源解析为 AST，并提供处理此 AST 的方法以提取所需的信息。输出/返回值是一个 JSON blob / JavaScript 对象。 + +**简单来说就是：它能提取组件的相关信息** + +### 安装 + +用 yarn 或 npm 安装模块： + +``` +yarn add react-docgen --dev + +npm install --save-dev react-docgen +``` + +> 关于它的 API 可以参考官方文档 [https://www.npmjs.com/package/react-docgen](https://www.npmjs.com/package/react-docgen) + +> 偷偷再分享一个高级版的 `react-styleguidist` [https://github.com/styleguidist/react-styleguidist](https://github.com/styleguidist/react-styleguidist) + +### 例子 + +我们先写一个人物的组件，里面包含 `姓名`、`爱好`、`事件回调` + +``` +// ./Persion/index.jsx + +import React, { Component } from 'react' +import PropTypes from 'prop-types' + +/** +* 人物组件 +* @description 这是关于人物组件的描述内容 +* @class Persion +* @extends {Component} +*/ +class Persion extends Component { + /** + * 处理睡觉的回调 + * @param {string} name 姓名 + */ + handleSleep = (name) => { + console.log(`${name} 开始睡觉`) + this.props.onSleep() + } + render() { + const { name, hobbies } = this.props + return ( +
+

姓名：{name}

+

爱好：{hobbies.join(',')}

+
+ ) + } +} +Persion.propTypes = { + /** + * 姓名 + */ + name: PropTypes.string.isRequired, + /** + * 爱好 + */ + hobbies: PropTypes.array, + /** + * 睡觉的事件回调 + */ + onSleep: PropTypes.func +} +Persion.defaultProps = { + name: '张三', + hobbies: ['睡觉', '打王者'] +} +export default Persion +``` + +我们定义了一个人物的组件，在组件**类注释**中描述了组件的基本信息, 同时在`propTypes`和`defaultTypes`中也对组件的属性参数进行了定义和**属性注释** + +组件的基本信息都写的差不多了，那么我们先开始使用`react-docgen`去提取组件的相关信息。 + +``` +// ./docgen.js + +const path = require('path') +const fs = require('fs-extra') +const reactDocs = require('react-docgen') +const prettier = require('prettier') + +// 读取文件内容 +const content = fs.readFileSync(path.resolve('./Persion/index.jsx'), 'utf-8') +// 提取组件信息 +const componentInfo = reactDocs.parse(content) +// 打印信息 +console.log(componentInfo) +``` + +这里写了一个简单的读取文件和解析的过程，并把提取到的信息打印出来，以下是组件信息提取后的内容 `componentInfo` + +``` +{ + "description":" + 人物组件 + @description 这是关于人物组件的描述内容 + @class Persion + @extends {Component}" + , + "displayName":"Persion", + "methods":[ + { + "name":"handleSleep", + "docblock":" + 处理睡觉的回调 + @param name 姓名 + ", + "modifiers":[ + + ], + "params":[ + { + "name":"name", + "description":"姓名", + "type":{ + "name":"string" + }, + "optional":false + } + ], + "returns":null, + "description":"处理睡觉的回调" + } + ], + "props":{ + "name":{ + "type":{ + "name":"string" + }, + "required":false, + "description":"姓名", + "defaultValue":{ + "value":"'张三'", + "computed":false + } + }, + "hobbies":{ + "type":{ + "name":"array" + }, + "required":false, + "description":"爱好", + "defaultValue":{ + "value":"['睡觉', '打王者']", + "computed":false + } + }, + "onSleep":{ + "type":{ + "name":"func" + }, + "required":false, + "description":"睡觉的事件回调" + } + } +} +``` + +关于 react-docgen 提取的信息中，解释下下面几个参数 + +- `displayName` 组件名称 +- `description` 组件的类注释 +- `methods` 组件定义的方法 +- `props` 组件的属性参数 + +其中这里的`props`是我们组件文档的核心内容，在提取的内容中，已经涵盖了属性的 **属性名、属性描述、类型、默认值、是否必传**。这些内容满足我们阅读组件文档所需要的属性信息。 + +有了所需的`componentInfo`信息之后，下一步我们需要把它转换成 `markdown` （至于为什么要用 markdown 我就不解释了 8） + +``` +// ./docgen.js + +// 生成markdown文档 +fs.writeFileSync(path.resolve('./Persion/index.md'), commentToMarkDown(componentInfo)) + +// 把react-docgen提取的信息转换成markdown格式 +function commentToMarkDown(componentInfo) { + let { props } = componentInfo + const markdownInfo = renderMarkDown(props) + // 使用prettier美化格式 + const content = prettier.format(markdownInfo, { + parser: 'markdown' + }) + return content +} +function renderMarkDown(props) { + return `## 参数 Props + | 属性 | 类型 | 默认值 | 必填 | 描述 | + | --- | --- | --- | --- | ---| + ${Object.keys(props) + .map((key) => renderProp(key, props[key])) + .join('')} + ` +} + +function getType(type) { + const handler = { + enum: (type) => + type.value.map((item) => item.value.replace(/'/g, '')).join(' \\| '), + union: (type) => type.value.map((item) => item.name).join(' \\| ') + } + if (typeof handler[type.name] === 'function') { + return handler[type.name](type).replace(/\|/g, '') + } else { + return type.name.replace(/\|/g, '') + } +} + +// 渲染1行属性 +function renderProp( + name, + { type = { name: '-' }, defaultValue = { value: '-' }, required, description } +) { + return `| ${name} | ${getType(type)} | ${defaultValue.value.replace( + /\|/g, + '|' + )} | ${required ? '✓' : '✗'} | ${description || '-'} | + ` +} + + +``` + +上面的转换 markdown 的代码其实做的事情比较少，主要是以下几个步骤 + +1. 遍历`props`对象中的每个属性， +2. 解析属性`prop`，提取`属性名`、`类型`、`默认值`、`必填`、`描述`、生成对应的 markdown 表格行。 +3. 生成 markdown 内容，通过`prettier`美化 markdown 代码。 + +经过转换后最终生成我们这个 markdown 的文件 + +``` +## 参数 Props + +| 属性 | 类型 | 默认值 | 必填 | 描述 | +| ------- | ------ | ------------------ | ---- | -------------- | +| name | string | '张三' | ✗ | 姓名 | +| hobbies | array | ['睡觉', '打王者'] | ✗ | 爱好 | +| onSleep | func | - | ✗ | 睡觉的事件回调 | + +``` + +### 拓展优化 + +这个案例只简单讲述了如何解析`props`并生成 markdown 的**参数 Props**模块的流程，在现实项目中，以上流程还有很多可以优化的空间，我们还可以通过很多自定义规则进行各种骚操作。 + +比如我们不希望把参数的**数据属性**（name、hobbies）和**回调属性**（onSleep）都放到同一个 Props 表格中，我们希望可以进行属性上的分类。 + +在属性描述的注释中，我们可以通过 @xx （或者 ¥%#@^!【】……你喜欢就好）进行不同的描述定义和分类，最终在属性解析的步骤中进行信息的深度的拆分解析分类，生成更加复杂多元的文档。 + +经过一些改造后，我们通过在**注释中添加不同规则的定义描述**，得到更优雅美观的文档模块 + +``` +Persion.propTypes = { + /** + * @text 姓名 + * @category data + */ + name: PropTypes.string.isRequired, + /** + * @text 爱好 + * @category data + */ + hobbies: PropTypes.array, + /** + * @text 睡觉的事件回调 + * @category event + */ + onSleep: PropTypes.func +} + +``` + +``` +## 数据 Data + +| 属性 | 类型 | 默认值 | 必填 | 描述 | +| ------- | ------ | ------------------ | ---- | ---- | +| name | string | '张三' | ✗ | 姓名 | +| hobbies | array | ['睡觉', '打王者'] | ✗ | 爱好 | + +## 事件 Event + +| 属性 | 类型 | 默认值 | 必填 | 描述 | +| ------- | ---- | ------ | ---- | -------------- | +| onSleep | func | - | ✗ | 睡觉的事件回调 | +``` + +当然还有很多比如`description`或者`methods`等都可以进行不同的解析并生成对应的`markdown模块`，数据信息提取出来了，其实最终怎么进行`ast`解析取决自身的具体业务要求。 + +## 小结 + +在日常开发的过程中，我们除了组件的代码编写外，还有很多流程上、边角上的工作需要做，这些事情往往都比较琐碎又必须要做。我们多借助工具去解决我们的工作中那些零星简单的任务，从而达到高（jiu）效（xiang）完（kuai）成（dian）工（xia）作（ban）的目标。开发者都是懒惰的（可能只有我？？），不然怎么会有这么多自动化的产物呢～ + +--- + +> 参考资料： +> [1] react-docgen 仓库文档 [https://github.com/reactjs/react-docgen#readme](https://github.com/reactjs/react-docgen#readme) From fbacd5f08df98b857894fcc036ee8ea86ef83f31 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=88=98=E6=AC=A2?= Date: Thu, 10 Sep 2020 19:56:03 +0800 Subject: [PATCH 4/6] =?UTF-8?q?=E6=8A=95=E7=A8=BF:=20=E6=9D=8E=E6=9D=B0-?= =?UTF-8?q?=E8=A7=84=E8=8C=83GIT=E4=BB=A3=E7=A0=81=E6=8F=90=E4=BA=A4?= =?UTF-8?q?=E4=BF=A1=E6=81=AF&=E8=87=AA=E5=8A=A8=E5=8C=96=E7=89=88?= =?UTF-8?q?=E6=9C=AC=E7=AE=A1=E7=90=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../_posts/2020-09-10-git-commit-control.md | 297 ++++++++++++++++++ 1 file changed, 297 insertions(+) create mode 100644 source/_posts/2020-09-10-git-commit-control.md diff --git a/source/_posts/2020-09-10-git-commit-control.md b/source/_posts/2020-09-10-git-commit-control.md new file mode 100644 index 0000000000..38b10c7200 --- /dev/null +++ b/source/_posts/2020-09-10-git-commit-control.md @@ -0,0 +1,297 @@ +title: 规范GIT代码提交信息&自动化版本管理 +subtitle: +cover: https://img11.360buyimg.com/imagetools/jfs/t1/123611/18/12202/317391/5f5a1073E7dc03d83/9f2adf4821068f28.jpg +category: 经验分享 +tags: + - git + - git commit + - Conventional Commits + - semver + - standard version + - commitizen +author: + nick: eijil +date: 2020-09-10 17:00:00 +--- +## 前言 + +`git`作为一个开发人员必不可少的工具，代码提交也是日常一个非常频繁的操作，如果你或你的团队目前对提交信息还没有一个规范或约束，那么你有必要看看本文的内容了。 + +## 为什么要规范提交信息 + +首先规范提交信息肯定是有必要的，简单总结下几点好处： + +* 让项目的维护或使用人员能了解提交了哪些更改 +* 清晰的历史记录，可能某天自己就需要查到呢 +* 规范的提交记录可用于自动生成修改日志(CHANGELOG.MD) +* 基于提交类型，触发构建和部署流程 + + +## 使用什么规范 + +**`Conventional Commits`(约定式提交规范)**，是目前使用最广泛的提交信息规范，其主要受[AngularJS规范](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines)的启发,下面是一个规范信息的结构： +``` +[optional scope]: +//空一行 +[optional body] +//空一行 +[optional footer(s)] +``` +### 规范说明 + + +**`type`** 提交的类别，必须是以下类型中的一个 + +``` +feat：增加一个新功能 +fix：修复bug +docs：只修改了文档 +style：做了不影响代码含义的修改，空格、格式化、缺少分号等等 +refactor：代码重构，既不是修复bug，也不是新功能的修改 +perf：改进性能的代码 +test：增加测试或更新已有的测试 +chore：构建或辅助工具或依赖库的更新 + +``` +**`scope`** 可选，表示影响的范围、功能、模块 + +**`subject`** +必填，简单说明，不超过50个字 + +**`body`** +选填，用于填写更详细的描述 + +**`footer`** +选填，用于填关联`issus`,或`BREAK CHANGE` + +**`BREAKING CHANGE`** + +必须是大写，表示引入了破坏性 API 变更，通常是一个大版本的改动，`BREAKING CHANGE:` 之后必须提供描述，下面一个包含破坏性变更的提交示例 +``` +feat: allow provided config object to extend other configs + +BREAKING CHANGE: `extends` key in config file is now used for extending other config files +``` + + +>更详细的说明请看[约定式提交规范](https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/#%e7%ba%a6%e5%ae%9a%e5%bc%8f%e6%8f%90%e4%ba%a4%e8%a7%84%e8%8c%83) + + +### 如何约束规范 + +怎么确保每个提交都能符合规范呢，最好的方式就是通过工具来生成和校验，`commitizen`是一个nodejs命令行工具，通过交互的方式，生成符合规范的git commit，界面如下： + +![](https://github.com/commitizen/cz-cli/raw/master/meta/screenshots/add-commit.png) + +开始安装: + +``` +# 全局安装 +npm install -g commitizen +# 或者本地安装 +$ npm install --save-dev commitizen +# 安装适配器 +npm install cz-conventional-changelog +``` +`packages.json`在配置文件中指定使用哪种规范 + +``` js +... + "config": { + "commitizen": { + "path": "cz-conventional-changelog" + } + } +``` +安装完成后可以使用`git cz` 来代替`git commit`,然后根据提示一步步输入即可 + +### 格式校验commitlint +可能你不想每次都通过交互界面来生成，还是想使用`git commit -m 'message'`，那么为了确保信息的正确性，可以结合`husky`对提交的信息进行格式验证 + +安装依赖 +``` bash +npm install --save-dev @commitlint/{config-conventional,cli} +# 安装husky +npm install --save-dev husky + +``` +添加 `commitlint.config.js`文件到项目 +``` bash +echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js +``` +`package.json`配置 +``` + +#git提交验证 +"husky": { + "hooks": { + "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" + } + }, +``` + +OK到这一步就完成了，最后给你项目README.MD加上一个`commitizen-friendly`的标识吧 +``` +[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/) +``` + +[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/) + +## 自动版本管理和生成CHANGELOG + +规范化的提交信息除了能很好描述项目的修改，还有一个很好的作用就是能根据提交记录来生成CHANGELOG.MD和自动生成版本号等功能。 + + +### standard-version + +一个用于生成`CHANGELOG.md`和进行`SemVer(语义化版本号)`发版的命令行工具 + +主要功能： +* 自动修改最新版本号，可以是`package.json`或者自定义一个文件 +* 读取最新版本号，创建一个最新的`git tag` +* 根据提交信息，生成`CHANGELOG.md` +* 创建一个新提交包括 `CHANGELOG.md`和`package.json` + + +### 语义化版本控制(SemVer) + +先简单了解下什么是语义化的版本控制，其是由`GitHub`发起的一份用于规范版本号递增的规则， +##### 版本格式 +主版本号.次版本号.修订号，版本号递增规则如下： + +* 主版本号(major)：当你做了不兼容的 API 修改， +* 次版本号(minor)：当你做了向下兼容的功能性新增，可以理解为Feature版本， +* 修订号(patch)：当你做了向下兼容的问题修正，可以理解为Bug fix版本。 + +先行版本号可以加到“主版本号.次版本号.修订号”的后面，作为延伸。 + +##### 先行版本 +当即将发布大版本改动前，但是又不能保证这个版本的功能 100% 正常，这个时候可以发布先行版本： + +* alpha: 内部版本 +* beta: 公测版本 +* rc: 候选版本(Release candiate) + +比如：1.0.0-alpha.0,1.0.0-alpha.1,1.0.0-rc.0,1.0.0-rc.1等。 + + `standard-version` 会根据提交的信息类型来自动更改对应的版本号,如下: +* feat: 次版本(minor)+1 +* fix: 修订号(patch) +1 +* BREAK CHANGE: 主板号(marjor) +1 + +> `standard-verstion` 生成的`CHANGELOG`只会包含`feat`,`fix`,`BREACK-CHANGE`类型的提交记录 + + +#### 使用 +``` bash +npm i --save-dev standard-version +``` + +添加`npm script` + +``` +{ + scripts:{ + "release": "standard-version", + "release:alpha": "standard-version --prerelease alpha", + "release:rc": "standard-version --prerelease rc" + } +} +``` +执行： +``` bash +# npm run script +npm run release +# or global bin +standard-version +``` +或者你想指定发行版本号： + +``` bash +#指定类型 patch/minor/marjor +npm run release -- --release-as patch +#指定版本号 +npm run release -- -- release-as 1.1.0 +``` + +##### 生命周期 + +* `prerelease`:所有脚本执行之前 +* `prebump`/`postbump`: 修改版本号之前和之后 +* `prechangelog`/`postchangelog`:生成changelog和生成changelog之后 +* `pretag`/`postag`:生成tag标签和之后 + +`standard-version`本身只针对本地，并没有`push`才操作，我们可以在最后一步生成tag后，执行push操作，在`paceage.json`中添加 +``` +"standard-version": { + "scripts": { + "posttag": "git push --follow-tags origin master && npm publish" + } + } +``` + + + +还有更多配置功能自行查阅 [官方文档](https://github.com/conventional-changelog/standard-version) + +#### 其它类似工具 +除了`standard-version`,还有其它类似的工具,有兴趣可以去了解下 +* [semantic-release](https://github.com/semantic-release/semantic-release) +* [lerna](https://lerna.js.org/) + + +## 修改Git Commit + +为了使`CHANGELOG.MD`更能加直观看到每个版本的修改，我们尽量保证每次提交都是有意义的，但实际开发过程中，不可避免会提交了一些错误的commit message，下面介绍几个`git`命令来修改`commit` + + +### 1 修改最后一次提交 +`git commit --amend` + +该命令会创建一个提交并覆盖上次提交，如果是因为写错或者不满意上次的提交信息，使用该命令就非常适合。 +### 2 合并多条提交 +`git reset --soft [commitID]` + +如果你想合并最近几条提交信息的话，那么就需要使用上面的命令来操作，指定要撤销的ccommitId,该命令会保留当前改动并撤销指定提交后的所有commit记录，如果不指定ID的话可以使用HEAD~`{num}` 来选择最近`{num}`条提交 +``` +git reset --soft HEAD~2 #合并最近两条提交 +git commit -m 'feat: add new feat' +``` +>带 `--soft` 参数的区别在于把改动内容添加到暂存区 相当于执行了`git add .` + +### git rebase -i + +`git rebase`的功能会更加强大，如果我想修改最近3条提交记录，执行 +``` bash +git rebase -i HEAD~3 +``` +会出现如下编辑器界面(vim编辑器): + + +![](https://img14.360buyimg.com/imagetools/jfs/t1/146374/23/7928/299480/5f5994e4E612057a2/96c528644441ab76.png) + +上面显示的是我最近3条提交信息 ，下面是命令说明， +修改方式就是将commit信息前的`pick`改为你需要的命令，然后退出`:wq`保存 + +下面是常用的命令说明： +``` +p,pick = 使用提交 +r,reword = 使用提交，但修改提交说明 +e,edit = 使用提交，退出后使用git commit --amend 修改 +s,squash = 使用提交，合并前一个提交 +f,fixup = 和squash相同，但丢弃提交说明日志 +d,drop = 删除提交，丢弃提交记录 +``` + +## 最后 +文本主要介绍了如何规范`git commit`和自动语义化版本管理，以及如何修改`git commit`,遵循一个规范其实没比之前随意填写信息增加多少工作量，但依赖规范却可以实现更多提升效率的事情。 + +## 参考 +* [conventional commits](https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4) + +* [standard version](https://github.com/conventional-changelog/standard-version) + +* [semver.org](https://semver.org/lang/zh-CN/) + +* [Semver(语义化版本号)扫盲](https://juejin.im/post/6844903591690534926) + From f02d7c383949258a14251ea8baf139770f70eb80 Mon Sep 17 00:00:00 2001 From: liuhuan14 Date: Mon, 28 Sep 2020 13:44:18 +0800 Subject: [PATCH 5/6] =?UTF-8?q?=E6=8A=95=E7=A8=BF=EF=BC=9Alillian=20vue3?= =?UTF-8?q?=20taro3=20=E6=96=87=E7=AB=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2020-09-25-taro-vue3.md | 410 ++++++++++++++++++++++++++ 1 file changed, 410 insertions(+) create mode 100644 source/_posts/2020-09-25-taro-vue3.md diff --git a/source/_posts/2020-09-25-taro-vue3.md b/source/_posts/2020-09-25-taro-vue3.md new file mode 100644 index 0000000000..6bdc0ca2ba --- /dev/null +++ b/source/_posts/2020-09-25-taro-vue3.md @@ -0,0 +1,410 @@ +title: 使用 Vue3 开发小程序 +subtitle: Vue3的新特性主要有 Composition API、Teleport、Fragments 等。我们是否也可以在小程序开发中使用这些特性呢？ +cover: https://img14.360buyimg.com/ling/jfs/t1/114796/40/19245/125315/5f715516E5765ae26/2375d621a3c73e76.png +category: 小程序 +tags: + - Vue3 + - Taro3 + - Taro + - 小程序 +author: + nick: lillian +date: 2020-09-28 09:00:00 +--- + +## 前言 + +9 月 19 日凌晨，Vue3 在经过多个开发版本的迭代后，终于迎来了它的正式版本，"One Piece" 的代号也昭示了其开拓伟大航路的野心。 + +Vue3的新特性主要有 Composition API、Teleport、Fragments 和 ` +``` +编译运行微信小程序 +```plain +npm run dev:weapp +``` +编译后，打开微信开发者工具导入编译后的`dist`目录，首页内容和编译成 H5的表现都如下图： +![图片](https://uploader.shimo.im/f/pzxlgUkWCEgGpvdC.png!thumbnail) + +## 验证Taro3对Vue3的支持度 + +### Composition API + +写个比较简单的 todolist 计数组件，假设目前已有 4 项代办事项，点击后将新增一项。这里会使用到Composition API 思路，以及 computed计算属性。 + +在用户点击时，第二行“当前操作新增”会根据点击次数递增，总计条数会在 4的基础上累加。 + +```plain + + +``` +页面表现如下所示，可见对于 Composition API 的支持的还是不错的。 + +![todo计数](https://img14.360buyimg.com/imagetools/jfs/t1/122176/18/13461/1349845/5f6c5d14Eaffd062c/f36c7a7279f8aac6.gif) + +### Teleport + +写个初次登录用户的欢迎弹窗。用户名从`index.vue`传入。首页代码如下： + +```plain + +``` +在 Toast.vue 中，我们会写个属性 to 为 teleportToast 的 Teleport 组件，代码如下： +```plain + + + +``` +在 H5 下是正常显示的，弹窗展示以及关闭功能效果如下；在小程序上却报错了，Taro 团队还需要加把劲： + +![Teleport](https://img10.360buyimg.com/imagetools/jfs/t1/111884/14/18645/2307115/5f6c6e91E963e9fcc/0b7230301e9d2e0a.gif) + +### Fragments + +Fragments 特性已经在上面的例子中得到验证，使用没有问题。 + +### script setup 语法糖 + +我们尝试一下` +``` +上述`script`标签里的代码效果等同于下面： +```plain + +``` +调用它的代码传入 mgs 如下： +```plain + +``` +运行后，小程序和 H5 都是支持的，页面整体表现如下： + +![script setup 语法糖](https://img10.360buyimg.com/imagetools/jfs/t1/132702/4/11153/1478203/5f705361E4db3e0cc/d32765423246de84.gif) + +可以看到，运用新特性进行开发，代码书写更加便捷，逻辑更清晰。 + +### style vars 语法糖 + +` +``` +调用它的页面里的代码如下： +```plain + + +``` +小程序和 H5 都没有问题，功能效果如下： + +![style vars 语法糖](https://img11.360buyimg.com/imagetools/jfs/t1/146777/39/9447/1836911/5f702d5eE52e470f9/dea5082ff993a478.gif) + +## 结语 + +我们将上述几个Demo 整合在一个项目中，放在[Github](https://github.com/lillian98/vue3)上，有兴趣的同学可以看看。在线预览地址在[这里](https://lillian98.github.io/vue3/dist/#/pages/index/index)。 + +经过验证，Taro3 支持使用最新的Vue3开发多端应用，相比之下H5的支持度更好一些。 + +值得一提的是，Taro 团队在技术上一直保持进取，在Taro2.0 版本支持了ReactHooks；根据[Taro RFCS](https://github.com/NervJS/taro-rfcs/blob/master/rfcs/0001-vue-3-support.md)，早在`2020-06-03`也已经打算支持Vue3 了。截至目前，Taro 对 Vue3 的支持在小程序端的稍有补足，希望 Taro 团队可以早日补足这个短板。 + +推荐文章： + +* [Vue3和React ](https://zhuanlan.zhihu.com/p/133819602)[H](https://zhuanlan.zhihu.com/p/133819602)[ooks对比](https://zhuanlan.zhihu.com/p/133819602) +* [SWR](https://github.com/vercel/swr) +* [自定义渲染器的应用](http://hcysun.me/vue-design/zh/renderer-advanced.html#%E8%87%AA%E5%AE%9A%E4%B9%89%E6%B8%B2%E6%9F%93%E5%99%A8%E7%9A%84%E5%BA%94%E7%94%A8) + +参考文章： + +* [1][Compsition API](https://v3.cn.vuejs.org/guide/composition-api-introduction.html) +* [2][Teleport](https://v3.cn.vuejs.org/guide/teleport.html#%E4%B8%8E-vue-components-%E4%B8%8E-vue-components-%E4%B8%80%E8%B5%B7%E4%BD%BF%E7%94%A8) +* [3]`