Vue（或其他文件）在vscode中的格式问题

Vue总有一项令我不爽的一点，那就是，不管他的默认格式化工具是现在的Volar也好，还是以前的Vuter也罢，总会和我的Eslint配置文件冲突。

索性我就将默认的vue格式化工具交给Eslint，如下:

1
2
3
4
5
6
7
8
// settings.json
...
"[vue]": {
        "editor.defaultFormatter": "dbaeumer.vscode-eslint",
        "editor.formatOnSave": true,
        "editor.formatOnType": false
    },
...

但是很快我就发现了问题，ESlint能管辖 ts/js， 但是没法管到 less/css 和 html 部分，所以我不得不研究几个方案来解决这个膈应人的问题

方案1: 把 ts/js 代码拆成单独的文件，形如:

1
2
3
// App.vue
<script setup lang="ts" src="/path/to/script.ts"></script>
...

好家伙，人家Vue费劲心思让你模块化你直接给人家拆了，我觉得不行。

方案2: 既然ESlint不能管到这些文件，我直接让他管辖到这部分不就行了？

我的结论是：想法很好，太麻烦了，不弄

方案3: 让Format工具按照顺序执行，先用Volar格式化vue文件，再用ESlint格式化 ts/js 代码块。

我的结论：可接受的方案

使用VScode插件Multiple Formatters，接着去settings.json设置Formatter的顺序, 如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// settings.json
...
 "[vue]": {
        // 此行表示将vue的formatter交给 multi-formatter 插件处理
        "editor.defaultFormatter": "Jota0222.multi-formatter",
        // 此处定义处理顺序
        "multiFormatter.formatterList": [
            "Vue.volar",
            "dbaeumer.vscode-eslint"
        ],
        "editor.formatOnSave": true,
        "editor.formatOnType": false
    },
...

展开全文 >>

梦的碎片：其二

海风 帐篷 还有
疲累的背包 你的眼睛
分辨不出 立体
还是 平面的 夜
已经过半

冷冽和鸟 湿透 头疼欲坠
梦的早晨 冰箱里 还剩下
半个 冻西瓜
60°C的温水 刚刚好
冲泡 跋涉的晕厥

碎石子 沙滩 还有
破碎的脚印 人如浪潮般
200毫升 雨水 天地深且浅
迟钝的海鸟 湿漉漉
连成 漫长地平线

宁静地汇入 梦中的那片海
眼泪和困惑 如细沙般 风干
点点摇曳的 星光 点亮了
我下半场的路

———— 下面的内容由GPT生成 ————

在海风中，我搭起了帐篷，背着疲惫的背包，眼睛望向夜空。然而，我发现无法分辨出立体还是平面的夜景，因为夜已经过半。

寒冷的风和湿润的空气让我头疼欲裂，带来了令人困惑的梦境。冰箱里只剩下半个冻西瓜，如同60°C的温水般刚刚好，我喝下它来缓解旅途的晕厥。

脚下是碎石子和沙滩，还有破碎的脚印，我如同浪潮般行走其中。200毫升的雨水在天地间浅浅深深流动，海鸟变得迟钝而湿漉漉，地平线连成漫长的一片。

我宁静地融入梦中的那片海洋，与自然合为一体。即使身心疲惫，我仍能在梦中找到平静和宁愿。眼泪和困惑如细沙般风干。点点摇曳的星光点亮了我下半场的路程，给予我希望与勇气。我继续前行，脚步坚定，心中充满着对未来的期待和渴望。

展开全文 >>

一年前，我做了一个决定...

内容已上锁

展开全文 >>

在机场，为那些闪光的小事告别

内容已上锁

展开全文 >>

梦的碎片：其一

内容已上锁

展开全文 >>

作弊小技巧：一招判断this所属上下文

Javascript的函数闭包，就是在调用函数时，通过返回一个携带该函数上下文的环境，获取本不可以被外部访问的数据。

下面是一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Example 1

function a () {
    let x = 1
    a.__proto__.add = ()=> x++
    return function(){return x}
}

const x = a() // => ƒ (){return x}
x() // => 1
a.add() // or x.add()
x() // => 2

注意⚠️：正常的函数在执行完毕后，会通过GC回收函数里被创建的资源。但是因为通过返回函数闭包（包含函数上下文），导致在函数中创建的所有变量（即使它们原本的目的只是作为临时变量）都被保存了下来。

上下文

闭包由于有被执行函数的完整上下文，所以可以通过 this 关键字获取函数内对应的变量。如：

1
2
3
4
5
6
7
8
9
10
11
12

// Example 2

function b () {
    const x = 1
    this.value = function (){return x}
    return this
}

b().x // => undefined
b().value() // => 1

由于变量x并未挂载到上下文this上，所以在这里显示为未定义。

接下来，我们把问题复杂化一点，看下面这个例子，来感受一下上下文this作用域的变化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Example 3

function b () {
    b.x = 1
    b.__proto__.value = function (){return this.x}
    return function () {
        this.x = 2
        return this
    }
}

const a = b() // => ƒ () { this.x = 2; return this }

a.x = 123
a.value() // => 123

b.value() // => 1

执行a.value()时, this.x指向的是a.x；执行b.value()时, this.x指向的是b.x。如果在调用a.value()前不对a.x赋值，那么this.x指向undefined。

通过这个规律，我们其实可以发现，this指向的上下文，是由调用方提供的。

  • 而特别地：
1
2
3
4

a().x // => 2
new a() // => {x: 2}

1.当直接调用函数时(a())，此时函数a没有被任何对象调用，那么this指向一个全局对象Window(仅限在浏览器中)。所以在 Example 2 中的 this实际也是指向Window对象。

2.使用new关键字时，会生成一个空的上下文对象({}), 然后根据函数内部逻辑，将需要的数据挂载到其中，此时this指向这个新的对象。

展开全文 >>

让你的Hexo变成单页面应用

在开始之前，不妨先打开这个页面，播放一首音乐，再点击我的头像返回来。

你是不是会好奇，明明是由Hexo生成的静态页面，为什么没有触发浏览器刷新？

静态页面虽然对SEO友好，但是却让访客的浏览体验不佳——现如今几乎没有不需要进行交互的网页。而只需要使用Fetch API，将页面作为一种资源异步取得，再由Javascript进行解析和局部替换，就让整个网站看起来像是单页应用了

1
2
<!-- html -->
<a href="/audio/" onclick="onEvent(event);return false">声 音</a>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
// typescript

async function _appendScript(element: HTMLScriptElement) {
    return new Promise((resolve) => {
        if (!element.src) {
            // e.innerText = element.innerText
            return
        }
        const e = document.createElement('script')
        document.body.appendChild(e)
        e.src = element.src
        e.onload = () => {
            resolve({})
        }
    })

}

/**
 * 模拟单页面应用
 * @param event
 */
async function onEvent(event: MouseEvent): Promise<void> {
    const el = event.target as HTMLLinkElement
    if (!el.href) {
        return onEvent({ target: el.parentElement } as any)
    }

    const res = await fetch(el.href)
    const data = await res.text()
    const domparser = new DOMParser()
    const doc = domparser.parseFromString(data, 'text/html')

    window.history.pushState(null, doc.title, el.href)

    document.title = doc.title
    document.body = doc.body
    let scripts: HTMLScriptElement[] = doc.body.querySelectorAll('script') as any
    if (!scripts) scripts = []
    else scripts = Array.from(scripts)

    for (let i = 0; ; i++) {
        if (i >= scripts.length) {
            break
        }
        const s = scripts[i]
        await _appendScript(s)
    }

}

展开全文 >>

Express的两种路由风格

在讨论Express框架的路由风格前，先让我们解决一下 async/await 的问题。

在Express框架下的路由，通常写法如下：

1
2
3
4
5
6
7
import * as express from 'express'

const router = express.Router()

router.get('/OK', (req, res) => {
    res.send('OK')
})

对于一般的任务，如使用服务的渲染页面，重定向或者读取文件，都不会有问题。因为这些任务都有一个特征：它们都是同步的（或是提供同步的调用接口）

但是在服务器上，很多任务是异步的，而要命的是某些异步方法执行的结果，是另外一些任务的前置条件，例如下面这个例子，先需要获取User对象，才能获取对应的user.token:

1
2
3
4
5
6
7

router.get('/OK', async (req, res) => {
    const user = await User.find({id: 1})
    const data = await AsyncRedis.get(user.token)
    res.resify(data)
})

如果这个时候 await User.find({id: 1}) 抛出异常，那么整个node进程会退出。也即：由async/await抛出的异常不会被errorHandler（如果有的话）所捕获。

当然，直接在路由中try/catch可以解决这个问题:

1
2
3
4
5
6
7
8
9
10
11
12

router.get('/OK', async (req, res, next) => {
    try {
        const user = await User.find({id: 1})
        const data = await AsyncRedis.get(user.token)
        res.resify(data)
    } catch (e) {
        next(e)
    }
})


在捕获异常后，交给下一个中间件处理。不过，真的有必要在每个路由中重复一遍这个吗…?

将路由初始化之前，试着引入下面的代码，你会发现，在路由里可以自由使用 async/await 了！这是因为下方的代码直接对Router对象进行了修改，相当于提前将try/catch植入到实际的路由事件中… 等等，这种操作是不是很熟悉，是不是有点AOP(面向切面编程)的感觉了?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// typescript
/**
 * Copy from https://github.com/davidbanham/express-async-errors
 *
 */
import { Router } from 'express'
// @ts-ignore
import Layer = require('express/lib/router/layer')

const last = (arr = []) => arr[arr.length - 1]
const noop = Function.prototype

function copyFnProps (oldFn: { [x: string]: any }, newFn: { (...args: any[]): any;[x: string]: any }) {
    Object.keys(oldFn).forEach((key) => {
        newFn[key] = oldFn[key]
    })
    return newFn
}

function wrap (fn: { [x: string]: any; apply?: any; length?: any }) {
    const newFn = function newFn (...args: any[]) {
        // @ts-ignore
        const ret = fn.apply(this, args)
        const next = (args.length === 5 ? args[2] : last(args as any)) || noop
        if (ret && ret.catch) ret.catch((err:Error) => next(err))
        return ret
    }
    Object.defineProperty(newFn, 'length', {
        value: fn.length,
        writable: false,
    })
    return copyFnProps(fn, newFn)
}

function patchRouterParam () {
    const originalParam = Router.prototype.constructor.param
    Router.prototype.constructor.param = function param (name: any,
        fn: { (...args: any[]): any;[x: string]: any; apply?: any; length?: any }
    ) {
        fn = wrap(fn)
        return originalParam.call(this, name, fn)
    }
}

Object.defineProperty(Layer.prototype, 'handle', {
    enumerable: true,
    get () {
        return this.__handle
    },
    set (fn) {
        fn = wrap(fn)
        this.__handle = fn
    },
})

patchRouterParam()

同样的，对于Express的路由来说，既有标准的中间件风格，也有使用装饰器的AOP风格

中间件

一个Http请求经过Express服务器时，就像水流经过处理厂，一开始可能有沉淀装置，然后可能有化学净水装置，再然后是物理净水装置，最后经过二次净化后流出。这些装置就像是Express中的各种组件一样，目标是通过这些组件的组装，对Http请求作出处理和响应。这些组件被称作中间件, 一个典型例子如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
app.use(function (req, res, next) {
    res.header('Access-Control-Allow-Origin', '*')
    res.header('Access-Control-Allow-Headers', 'Content-Type, X-Refresh-Token, Authorization')
    res.header('Access-Control-Allow-Methods', 'GET,POST,DELETE')
    next()
})

...

const requestInterceptor = async (req: Request, res: Response, next: NextFunction): Promise<void> => {
    ...
    next()
}

app.use(requestInterceptor)
app.use('/', router)
app.use('/test', TestHandler)
app.use(errorHandler)

...

app.use标志着括号里的函数被作为一个中间件，来处理流经的Http请求；而第一个参数是string的则表示，对应的路径的请求，交给后面的中间件处理。每个中间件接受三个参数,分别是：req: Request，res: Response，next: NextFunction

中间件通过调用 next() 参数来传递 Http请求，如果不调用 next()，Http请求将由该中间件响应(Http Response)

如果现在需要一个身份认证的前置逻辑，对于中间件，这样写:

1
2
3
4
5
6
7
8
9
10
async function Auth(req, res, next) {
    ... // do something
    next()
}

app.use('/', Auth, router)
// 或者
router.get('/OK', Auth, (req, res) => {
    ... // do something
})

注意这里的next(),这是一个中间件不可缺少的调用。使用中间件可以很轻易地实现诸如拦截器，身份验证的逻辑。

装饰器

如果说使用中间件是标准风格的话，那么装饰器风格无疑就很炫酷了。

1
2
3
4
5
6
7
8

class APIHandler {
    @GET('/OK')
    ok (req: express.Request, res: express.Response) {
        res.resify.success()
    }
}

它带来了声明式编程的体验，你总是能一眼通过装饰器洞察到它们的实际目的。

使用装饰器的路由原理也不同于使用中间件，装饰器更像是截断了原来的管道（而中间件是在原来的管道前/后添加新的管道），再用新工艺重新封装起来。

1
2
3
4
5
6
7
8
9
10
11
12

import * as express from 'express'

export const router = express.Router()

export function GET (path: string): MethodDecorator {
    return function ( target: any, propertyKey: string | symbol, fn: PropertyDescriptor) {
        router.get(path, fn.value)
        return fn
    }
}

在装饰器的定义函数中，我们没有发现熟悉的next()，甚至整个函数非常抽象，需要一点学习成本。因为@GET('/OK')在程序启动时就运行了，所以在执行router.get(path, descriptor.value)时，路由和Handler被绑定。当Express调用对应路由的handler时，将由这个被定义的ok方法处理。而在代码层面上，我们并不实际调用APIHandler().ok(req, res)。

实际上这个例子并不好，我们只是简单地进行了路由绑定而已。下面一个例子，我们为刚才的路由添加一个身份验证的装饰器:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

export function Auth (): MethodDecorator {
    return function (target: any, key: string, fn: PropertyDescriptor) {
        const origin = fn.value
        fn.value = async function (req: Request, res: Response, next: NextFunction) {
            ... // do something
            const user = await UserSerivce.find({id: req.uid})
            res.user = user
            const result = await origin.apply(this, [req, res, next])
            return result
        }
        return fn
    }
}

class APIHandler {
    @GET('/OK')
    @Auth()
    ok (req: express.Request, res: express.Response) {
        res.resify.success()
    }
}

看，在实际执行handler之前，我们偷偷做了点工作（把user对象挂载到 res: Response 对象上）

这不就是中间件的作用吗？只不过这次，我不需要手动调用next()了，定义Auth装饰器时，写法比定义一个中间件更复杂。好处就是带来了声明式这么直观、高效地使用方式。

展开全文 >>

CI...或是...更简单的东西

CI(持续集成)，每次代码更新时，通过自动化任务将改动应用到服务器。CI对编译型语言很友好，比如一个企业级的Java程序启动，需要一连串的N个步骤，不仅繁琐还费时，有时仅仅是一些小改动，就叫人重复做一些不必要的工作。

比如老牌的自动集成软件Jenkins，就做的非常好，通过它的GUI，开发者可以很直观的了解当前项目的状态。并且随着CI的发展，应用程序容器化也成了一种趋势，有一段时间，似乎不用用Docker和K8S就不配叫做程序员（可能现在也是），还诞生了一个离谱的词汇(DevOps)…

声明一点，我很喜欢Jenkins，如果让我用Java或者一些其他的重型语言开发一个大项目，我肯定也会考虑使用它。但问题是，有些很小的项目……我觉得都不需要使用这么重的东西。

当然，是个人都会想要偷懒，不管这个项目有多小…

比如，一个node后端项目，在每次代码更新时，可能只需要 拉取代码 -> 编译源码 -> 重启服务 这么三个步骤。

那么，我们要做的事，就是捕获到代码推送事件(push event)，然后执行上面的三步操作。

展开 >>

展开全文 >>

这是一篇加密的文章

内容已上锁

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

                  jsonContent:
                meta: false
                pages: false
                posts:
                  title: true
                  date: true
                  path: true
                  text: false
                  raw: false
                  content: false
                  slug: false
                  updated: false
                  comments: false
                  link: false
                  permalink: false
                  excerpt: false
                  categories: false
                  tags: true